xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Richie <listmail@triad.rr.com>
To: Bruce Edge <bruce.edge@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: /etc/grub.d/09-xen for generating grub.cfg for hypervisor boot entries.
Date: Wed, 19 May 2010 13:07:37 -0400	[thread overview]
Message-ID: <4BF41AD9.6050806@triad.rr.com> (raw)
In-Reply-To: <AANLkTinZJ8O7X3wZd6hzkMIoltQdVAfjowsk4uEuxL9l@mail.gmail.com>

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@triad.rr.com 
> <mailto:listmail@triad.rr.com>> 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@lists.xensource.com
>         <mailto:Xen-devel@lists.xensource.com>
>         http://lists.xensource.com/xen-devel
>          
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

  reply	other threads:[~2010-05-19 17:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 22:30 /etc/grub.d/09-xen for generating grub.cfg for hypervisor boot entries Bruce Edge
2010-05-19  0:24 ` Richie
2010-05-19 16:04   ` Bruce Edge
2010-05-19 17:07     ` Richie [this message]
2010-05-19 17:11       ` Bruce Edge
2010-05-19 17:47         ` listmail
2010-05-19 18:09           ` Jeremy Fitzhardinge
2010-05-19 20:19             ` Richie
2010-05-19 22:23               ` Bruce Edge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF41AD9.6050806@triad.rr.com \
    --to=listmail@triad.rr.com \
    --cc=bruce.edge@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).