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 hyperviso

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