From: listmail <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:47:18 -0400 [thread overview]
Message-ID: <4BF42426.3040606@triad.rr.com> (raw)
In-Reply-To: <AANLkTilzNPl0BSemyJJXjB2YcjRVHk7ahWHBxwmn8ilR@mail.gmail.com>
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@triad.rr.com
> <mailto:listmail@triad.rr.com>> 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@triad.rr.com
> <mailto:listmail@triad.rr.com> <mailto: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>
> <mailto: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
> <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
>
next prev parent reply other threads:[~2010-05-19 17:47 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
2010-05-19 17:11 ` Bruce Edge
2010-05-19 17:47 ` listmail [this message]
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=4BF42426.3040606@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).