[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.