[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.



Yes that should do it and no corresponding boot/config-$(uname -r) means nothing will be generated for the respective kernel. There could also be a check for CONFIG_XEN=y to support Xenlinux kernels. That entry should not exist in pvops .config so a special menu entry tag could also be generated depicting kernel type if desirable. Those are things I might add in afterwards if you are not interested in them.

Bruce Edge wrote:
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 <mailto: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> <mailto: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>
               <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx
        <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>>

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

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

        _______________________________________________
        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®.