All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.