WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] /etc/grub.d/09-xen for generating grub.cfg for hypervis

Subject: Re: [Xen-devel] /etc/grub.d/09-xen for generating grub.cfg for hypervisor boot entries.
From: Bruce Edge <bruce.edge@xxxxxxxxx>
Date: Wed, 19 May 2010 10:11:55 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 19 May 2010 10:12:55 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:cc:content-type; bh=XjazIR5B6TRcxeExr5RNWWf8CXPNPiSsHRQbq6lkhp4=; b=vRtqM+PaloHlXsPPQB7/6kS8xybKeIIk9vsz1UlQZ7NZBQqqSHD+ItrGJvz/d9gbF8 vnwwqB0dq6k5QJF/QEutl72hc2Z8YRnkhey3XSPJyue+EK4OM/TBS6QAChcMbZOhgh+B HCbTnHnIQMNbstkQv80wpB9eQ/zUtPudlMVkw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=EbxGN2C615TY6qzIm5jO4rbhn3/cTWThcusOAfBUYyIPOSmVRC2G9dYcbR1Ox2mDYF Hs66945l2zFxh46vcf5Ex6Lbuxk57BkrkdFSPmjFkWGLG9Gf3OywGo67/150wFepL7k6 wOGaJQtbgZe/uyC6We0LBk5Lp3h3BYqurIZ9Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BF41AD9.6050806@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTingW_TH0NKssADO4xk0PbAbRDaXn6mbTXxEmqw6@xxxxxxxxxxxxxx> <4BF32FAB.7050900@xxxxxxxxxxxx> <AANLkTinZJ8O7X3wZd6hzkMIoltQdVAfjowsk4uEuxL9l@xxxxxxxxxxxxxx> <4BF41AD9.6050806@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Perhaps grepping for CONFIG_XEN_DOM0=y in the boot/config-XX would validate the dom0 kernel compatibility better then looking for -xen in the name.

-Bruce

-Bruce


On Wed, May 19, 2010 at 10:07 AM, Richie <listmail@xxxxxxxxxxxx> wrote:
Perhaps it goes without saying, but I don't think my suggestion for a xen in the image name check will be an accurate solution for someone that does not roll their own kernels.  I always know that my kernels have xen in the name when they are pvops/dom0 capable and sxen when they are Xenlinux.  Also, technically, for Xenlinux kernels, grub should not be generating bare metal boot entries.

If anything, this could also be used as a basis for a script that generates an initial 40_custom file.  That can then be hand edited before running update-grub.


Bruce Edge wrote:
Good points all. Will incorporate, retest and repost the resultant script.

Thanks

-Bruce


On Tue, May 18, 2010 at 5:24 PM, Richie <listmail@xxxxxxxxxxxx <mailto:listmail@xxxxxxxxxxxx>> wrote:

   I like the idea myself and I haven't seen anything in the wiki's
   other than manual creation steps.

   Just an opinion here, but why not use "dummy=dummy" as opposed to
   first parameter duplication?  My understanding is that dummy is
   used to avoid this same bug.  Either way we it avoids having to
   hardcode root= into the kernel cmdline .config parameter :)  I
   don't know if parameter duplication would break things when the
   bug is fixed or not, but the dummy parameter shouldn't.  I also
   think it might be viewed as something more familiar, perhaps self
   explanatory, whereas the parameter duplication may cause confusion.

   I skimmed the code and have not tested it.  I don't see that it is
   specifically trying to ensure that the kernel is Xenlinux or
   pvops...  Not that I know of a proper way to do such or if its
   even pratical.  Aren't most kernels now pvops (thus bootable under
   xen) but not necessarily dom0 capable?  I think a spin on this
   would be if one wanted to limit the Xen entries to kernels with
   "xen" (ie. --append-to-version) in the name.  Perhaps the code
   would change as follows?

   <snip>
   list=`for i in /boot/vmlinu[xz]-*xen* /vmlinu[xz]-*xen* ; do

         if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
       done`
   <snip>



   Bruce Edge wrote:

       If this has already been done, please forgive me. However, if
       not, I'd like to submit this as a mechanism for generating a
       bootable grub2 stanza for hypervisors.

       As the /etc/grub.d/* files rely on defaults in
       /etc/default/grub, I added the following Xen specific variable:

       GRUB_CMDLINE_XEN_DEFAULT="console=com1 115200,8n1
       dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin=true
       iommu=1,passthrough,no-intremap loglvl=all loglvl_guest=all
       loglevl=10 debug acpi=force apic=on apic_verbosity=verbose
       numa=on"

       The script itself is a hacked version of the10-linux that
       comes with grub2. This is 09-xen so it places it's boot
       entries ahead of the non-xen entries.
       The resulting grub.cfg entry looks like:

       ### BEGIN /etc/grub.d/09_xen ###
        insmod lvm
        set root=(system-dom0_0)
       menuentry "Xen osa-dom0 6.0.13-05, linux 2.6.32.12" {
              multiboot /boot/xen.gz /boot/xen.gz console=com1
       115200,8n1 dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin=true
       iommu=1,passthrough,no-intremap loglvl=all loglvl_guest=all
       loglevl=10 debug acpi=force apic=on apic_verbosity=verbose numa=on
              module /boot/vmlinuz-2.6.32.12 /boot/vmlinuz-2.6.32.12
       root=UUID=a3764d7d-6292-4f08-8ece-480e54c77229  ro
       earlyprintk=xen loglevel=10 debug acpi=force console=hvc0,115200n8
              module /boot/initrd.img-2.6.32.12
       /boot/initrd.img-2.6.32.12
       }
       ### END /etc/grub.d/09_xen ###

       Note the duplication of the first params. I believe there's a
       bug that drops the 1st param so this could be changed later.

       #! /bin/sh -e

       prefix=/usr
       exec_prefix=${prefix}
       libdir=${exec_prefix}/lib
       . ${libdir}/grub/update-grub_lib

       if [ "x${GRUB_DISTRIBUTOR}" = "x" ] ; then
        OS=GNU/Linux
       else
        OS="${GRUB_DISTRIBUTOR}"
       fi

       # Source grub defaults
       . /etc/default/grub

       # loop-AES arranges things so that /dev/loop/X can be our root
       device, but
       # the initrds that Linux uses don't like that.
       case ${GRUB_DEVICE} in
        /dev/loop/*|/dev/loop[0-9])
          GRUB_DEVICE=`losetup ${GRUB_DEVICE} | sed -e
       "s/^[^(]*(\([^)]\+\)).*/\1/"`
        ;;
       esac

       if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [
       "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
          || ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" ; then
        LINUX_ROOT_DEVICE=${GRUB_DEVICE}
       else
        LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
       fi

       test_gt ()
       {
        local a=`echo $1 | sed -e
       "s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\|old\)/~\1/g"`
        local b=`echo $2 | sed -e
       "s,.*/vmlinu[zx]-,,g;s/[._-]\(pre\|rc\|test\|git\|old\)/~\1/g"`
        if [ "x$b" = "x" ] ; then
          return 0
        fi
        dpkg --compare-versions "$a" gt "$b"
        return $?
       }

       find_latest ()
       {
        local a=""
        for i in $@ ; do
          if test_gt "$i" "$a" ; then
            a="$i"
          fi
        done
        echo "$a"
       }

       list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
              if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
            done`

       while [ "x$list" != "x" ] ; do
        linux=`find_latest $list`
        echo "Found linux image: $linux" >&2
        basename=`basename $linux`
        dirname=`dirname $linux`
        rel_dirname=`make_system_path_relative_to_its_root $dirname`
        version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
        alt_version=`echo $version | sed -e "s,\.old$,,g"`
        linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"

        initrd=
        for i in "initrd.img-${version}" "initrd-${version}.img" \
                 "initrd.img-${alt_version}"
       "initrd-${alt_version}.img"; do
          if test -e "${dirname}/${i}" ; then
            initrd="$i"
            break
          fi
        done
        if test -n "${initrd}" ; then
          echo "Found initrd image: ${dirname}/${initrd}" >&2
        else
          # "UUID=" magic is parsed by initrds.  Since there's no
       initrd, it can't work here.
          linux_root_device_thisversion=${GRUB_DEVICE}
        fi

        cat << EOF
        insmod lvm
        set root=(system-dom0_0)
       menuentry "Xen ${OS}, linux ${version}" {
              multiboot /boot/xen.gz /boot/xen.gz
       $GRUB_CMDLINE_XEN_DEFAULT
              module ${rel_dirname}/${basename}
       ${rel_dirname}/${basename}
       root=${linux_root_device_thisversion} $GRUB_CMDLINE_LINUX_DEFAULT
       EOF
        if test -n "${initrd}" ; then
          cat << EOF
              module ${rel_dirname}/${initrd} ${rel_dirname}/${initrd}
       EOF
        fi
        cat << EOF
       }
       EOF

        list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
       done


       -Bruce
       ------------------------------------------------------------------------

       _______________________________________________
       Xen-devel mailing list
       Xen-devel@xxxxxxxxxxxxxxxxxxx
       <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>

       http://lists.xensource.com/xen-devel
       


------------------------------------------------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel