From: Ian Campbell <ijc@hellion.org.uk>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Behaviour of update-grub when Xen enabled kernels are installed.
Date: Fri, 30 May 2008 08:45:59 +0100 [thread overview]
Message-ID: <1212133559.3747.25.camel@localhost.localdomain> (raw)
In-Reply-To: <20080528133930.GB26495@thorin>
[-- Attachment #1.1: Type: text/plain, Size: 2991 bytes --]
On Wed, 2008-05-28 at 15:39 +0200, Robert Millan wrote:
> No reply... if you're still interested in this, I suggest you contact
> the people who set the current behaviour and involve them in the discussion,
> to see if they have any objections to what you propose.
I've not had as much time to look at it recently as I would have liked
(and I'm just about to disappear for a long weekend).
I've got a pretty skanky patch which attempts to add paravirt support to
grub2's update-grub in a way that's a little more general (perhaps
lguest or some other h/v support would be useful).
I've attached it but don't think it is correct in all cases at the
moment (and some code just echoes "do foo" instead of doing it...).
Ian.
>
> On Sun, May 11, 2008 at 10:36:38AM +0100, Ian Campbell wrote:
> > Hi all,
> >
> > The version of update-grub in Debian's grub-legacy packages[0] has an
> > interesting feature where it attempts to detect when I kernel is
> > compiled for Xen and chooses to include it in the menu depending on
> > whether it is running inside a Xen guest domain or not[1].
> >
> > As described at [2] this behaviour has been broken by the latest kernels
> > which due to the paravirt_ops (CONFIG_PARAVIRT) framework which means
> > that these kernels are now bootable both native and as a Xen guest
> > domain.
> >
> > Robert asked me to bring the issue here and to ask the question of
> > whether or not this behaviour would be welcomed as a patch to grub 2.
> >
> > Personally I am not a fan of this behaviour since it causes the wrong
> > thing to occur in several circumstances, i.e. installing into a chroot
> > or switching back and forth between fully- and para-virtualised
> > operation and as time moves on CONFIG_PARAVIRT will become the norm and
> > the behaviour less necessary in general. What is the opinion of the grub
> > 2 devs?
> >
> > Cheers,
> > Ian.
> > [0] For those not familiar with Xen the classical Xen kernels cannot be
> > run on bare metal so there is an argument that it makes little sense to
> > include them in the menu for the control domain, conversely including a
> > native kernel in the menu for a guest domain is not terribly useful
> > either. CONFIG_PARAVIRT (2.6.22+) changes this and such kernel is now
> > bootable on native and under Xen.
> > [1]
> > http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/update-grub?view=auto
> > [2]
> > http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2008-April/004701.html http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2008-May/004821.html
> >
> >
> > --
> > Ian Campbell
> >
> > Waste not fresh tears over old griefs.
> > -- Euripides
>
>
>
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
--
Ian Campbell
"Here comes Mr. Bill's dog."
-- Narrator, Saturday Night Live
[-- Attachment #1.2: pv-update-grub.patch --]
[-- Type: text/x-patch, Size: 5014 bytes --]
? .pc
? patches
? v1
Index: util/grub.d/10_linux.in
===================================================================
RCS file: /cvsroot/grub/grub2/util/grub.d/10_linux.in,v
retrieving revision 1.10
diff -u -r1.10 10_linux.in
--- util/grub.d/10_linux.in 30 Apr 2008 11:06:27 -0000 1.10
+++ util/grub.d/10_linux.in 30 May 2008 07:44:35 -0000
@@ -78,11 +78,36 @@
echo "$a"
}
+paravirt="${GRUB_PARAVIRT_ENV:-detect}"
+echo "paravirt: $paravirt" >&2
+if [ "$paravirt" == "detect" ] ; then
+ if [ -e /proc/xen/capabilities ] || [ -e /sys/bus/xen ] ; then
+ paravirt="xen"
+ else
+ paravirt="native"
+ fi
+fi
+# Determine the config string to check for in this paravirtual environment.
+case "${paravirt}" in
+ xen) paravirt_guest="CONFIG_XEN=y" ;;
+ native) paravirt_guest= ;;
+ *) # Invalid? Call it native...
+ paravirt=native
+ paravirt_guest=
+ ;;
+esac
+echo "paravirt_guest: $paravirt_guest" >&2
+
list=`for i in /boot/vmlinu[xz]-* /vmlinu[xz]-* ; do
if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
done`
+xen_hv=`for i in /boot/xen-*.gz /xen-*.gz ; do
+ if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
+ done`
+xen_hv=${xen_hv_}
while [ "x$list" != "x" ] ; do
+ echo >&2
linux=`find_latest $list`
echo "Found linux image: $linux" >&2
basename=`basename $linux`
@@ -91,6 +116,37 @@
version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
alt_version=`echo $version | sed -e "s,\.old$,,g"`
+ config=
+ for i in "config-${version}" "config-${alt_version}"; do
+ if test -e "${dirname}/${i}" ; then
+ config="$i"
+ break
+ fi
+ done
+ if test -n "${config}" ; then
+ echo "Found config: ${dirname}/${config}" >&2
+ fi
+
+ is_paravirt=
+ is_paravirt_guest=
+ is_nonparavirt_xen=
+
+ if test -n ${config} ; then
+ if grep -q CONFIG_PARAVIRT=y ${dirname}/${config} ; then
+ is_paravirt=1
+
+ if test -n "${paravirt_guest}" && grep -q ${paravirt_guest} ${dirname}/${config} ; then
+ is_paravirt_guest=1
+ fi
+ fi
+
+ # Special case to handle pre-CONFIG_PARAVIRT Xen guests.
+ if ! grep -q CONFIG_PARAVIRT ${dirname}/${config} &&
+ grep -q CONFIG_XEN=y ${dirname}/${config} ; then
+ is_nonparavirt_xen=1
+ fi
+ fi
+
initrd=
for i in "initrd.img-${version}" "initrd-${version}.img" \
"initrd.img-${alt_version}" "initrd-${alt_version}.img"; do
@@ -103,31 +159,73 @@
echo "Found initrd image: ${dirname}/${initrd}" >&2
fi
- cat << EOF
+ echo "is_paravirt=$is_paravirt is_paravirt_guest=$is_paravirt_guest is_nonparavirt_xen=$is_nonparavirt_xen" >&2
+ emit=std
+ if [ "${paravirt}" != "native" ] && [ "$is_paravirt_guest" ] ; then
+ emit=pv
+ elif [ "${paravirt}" != "native" ] && [ ! "$is_paravirt_guest" ] ; then
+ if [ "${paravirt}" == "xen" ] && [ "$is_nonparavirt_xen" ]; then
+ # Allow old style non-CONFIG_PARAVIRT Xen kernels.
+ echo "allowing non-PARAVIRT Xen kernel $linux" >&2
+ emit=nonpvxen
+ else
+ echo "skip non-paravirt kernel $linux in guest domain. (B)" >&2
+ emit=none
+ #list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+ #continue
+ fi
+ else
+ if [ "$is_nonparavirt_xen" ]; then
+ echo "skip non paravirt Xen kernel $linux on native. (C)" >&2
+ emit=none
+ # skip xen kernels
+ #list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
+ #continue
+ fi
+ fi
+
+ if [ "${emit}" == "pv" ] || [ "${emit}" == "nonpvxen" ] ; then
+ if [ -n "${xen_hv}" ] ; then
+ echo "create xen stanzas for $xen_hv and Linux $version" >&2
+ if [ "${emit}" == "pv" ] ; then
+ emit="std" # Also emit a non-Xen entry for a paravirt kernel
+ else
+ emit=none # But not for an old-style -Xen kernel
+ fi
+ else
+ # If no hypervisor present then assume guest domain and emit a standard entry
+ emit="std"
+ fi
+ fi
+
+ if [ "${emit}" == "std" ] ; then
+ echo "create regular entry for $version" >&2
+ cat << EOF
menuentry "${OS}, linux ${version}" {
linux ${grub_dirname}/${basename} root=${GRUB_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}
EOF
- if test -n "${initrd}" ; then
+ if test -n "${initrd}" ; then
cat << EOF
initrd ${grub_dirname}/${initrd}
EOF
- fi
- cat << EOF
+ fi
+ cat << EOF
}
EOF
- cat << EOF
+ cat << EOF
menuentry "${OS}, linux ${version} (single-user mode)" {
linux ${grub_dirname}/${basename} root=${GRUB_DEVICE} ro single ${GRUB_CMDLINE_LINUX}
EOF
- if test -n "${initrd}" ; then
- cat << EOF
+ if test -n "${initrd}" ; then
+ cat << EOF
initrd ${grub_dirname}/${initrd}
EOF
- fi
- cat << EOF
+ fi
+ cat << EOF
}
EOF
+ fi
list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`
done
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2008-05-30 7:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 9:36 Behaviour of update-grub when Xen enabled kernels are installed Ian Campbell
2008-05-28 13:39 ` Robert Millan
2008-05-30 7:45 ` Ian Campbell [this message]
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=1212133559.3747.25.camel@localhost.localdomain \
--to=ijc@hellion.org.uk \
--cc=grub-devel@gnu.org \
/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.