Debian Bug report logs - #500336
grub - Misguides Xen images

version graph

Package: grub; Maintainer for grub is GRUB Maintainers <pkg-grub-devel@lists.alioth.debian.org>;

Reported by: Bastian Blank <waldi@debian.org>

Date: Sat, 27 Sep 2008 11:27:01 UTC

Severity: grave

Tags: patch

Found in version grub/0.97-47

Fixed in version grub/0.97-47lenny1

Done: Robert Millan <rmh@aybabtu.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Sat, 27 Sep 2008 11:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
New Bug report received and forwarded. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Sat, 27 Sep 2008 11:27:03 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: submit@bugs.debian.org
Subject: grub - Misguides Xen images
Date: Sat, 27 Sep 2008 13:26:24 +0200
Package: grub
Version: 0.97-47
Severity: grave

update-grub adds 2.6.26-1-686-bigmem with a Xen hypervisor to the grub
config. This image does not support to be loaded as initial domain by
the hypervisor.

Bastian

-- 
Vulcans do not approve of violence.
		-- Spock, "Journey to Babel", stardate 3842.4




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Sun, 05 Oct 2008 11:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Viehmann <tv@beamnet.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Sun, 05 Oct 2008 11:48:04 GMT) Full text and rfc822 format available.

Message #10 received at 500336@bugs.debian.org (full text, mbox):

From: Thomas Viehmann <tv@beamnet.de>
To: 500336@bugs.debian.org
Cc: Bastian Blank <waldi@debian.org>
Subject: possible solutions?
Date: Sun, 05 Oct 2008 13:43:10 +0200
Hi,

presently, grub scans the /boot/config-* for CONFIG_PARAVIRT aand
CONFIG_XEN to find xen dom0 kernels:

# Second new style CONFIG_PARAVIRT kernels with xen support. There is
# no distinction between xen0 and xenU in these kernels.
for ver in `grep -l CONFIG_PARAVIRT=y /boot/config* | sed -e
s%/boot/config-%%`; do
  if ! grep -q CONFIG_XEN=y /boot/config-$ver ; then

The most obivous choice of avoiding to select the wrong Debian-provided
kernel would be to look for /boot/config-*xen* kernels only.
This might, however, screw users building their own.
An alternative might be to this restriction for >= 2.6.2x kernels only.

A third option could be to look whether /var/lib/$VERSION/xen-versions
exists, but similar concerns may apply.

Opinions?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Fri, 10 Oct 2008 09:00:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Fri, 10 Oct 2008 09:00:05 GMT) Full text and rfc822 format available.

Message #15 received at 500336@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: 500336@bugs.debian.org
Subject: fix outline
Date: Fri, 10 Oct 2008 10:58:41 +0200
The current config variables are as following:
- CONFIG_XEN is set for any Xen capable image.
- CONFIG_PARAVIRT is set for the images which can do both.
- CONFIG_XEN_PRIVILEGED_GUEST is currently set for anything which can be
  booted via a hypervisor.

So images with CONFIG_XEN and no CONFIG_PARAVIRT must not show up as
normal bootable.

Bastian

-- 
There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Sat, 11 Oct 2008 13:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Felix Zielcke" <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Sat, 11 Oct 2008 13:03:02 GMT) Full text and rfc822 format available.

Message #20 received at 500336@bugs.debian.org (full text, mbox):

From: "Felix Zielcke" <fzielcke@z-51.de>
To: <500336@bugs.debian.org>
Cc: "Bastian Blank" <waldi@debian.org>
Subject: grub - Misguides Xen images
Date: Sat, 11 Oct 2008 14:58:05 +0200
Hi,

sorry for not replying directly but somehow the mails of this report got lost for me,

>update-grub adds 2.6.26-1-686-bigmem with a Xen hypervisor to the grub
>config. This image does not support to be loaded as initial domain by
>the hypervisor.

I don't get this Xen stuff
There is this [0] message from Ian Campbell which says that there's no way to dertermine
if a CONFIG_PARAVIRT=y + CONFIG_XEN=y runs in a Dom0 or not.

# diff -u config-2.6.26-1-*|egrep 'XEN|PARAVIRT'
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=8
+CONFIG_XENCTRL=y
CONFIG_PARAVIRT=y
-CONFIG_XEN_BLKDEV_FRONTEND=m
+CONFIG_XEN_BLKDEV_FRONTEND=y
-CONFIG_NETXEN_NIC=m
-CONFIG_XEN_NETDEV_FRONTEND=m
+CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y

So should we also grep for CONFIG_XENCTRL=y to be more on the safe side that this kernel can be loaded
with the Xen hypervisor?
There was a bugreport that we shouldn't look for *-xen-* in the filename, because some other thing uses xen too
which has nothing to do with the Xen virtualization if I remember correctly and for custom kernels this wouldn't work anyway. 




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Fri, 17 Oct 2008 21:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Viehmann <tv@beamnet.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Fri, 17 Oct 2008 21:45:06 GMT) Full text and rfc822 format available.

Message #25 received at 500336@bugs.debian.org (full text, mbox):

From: Thomas Viehmann <tv@beamnet.de>
To: 500336@bugs.debian.org
Cc: Bastian Blank <waldi@debian.org>
Subject: patch for grub detection
Date: Fri, 17 Oct 2008 23:40:07 +0200
[Message part 1 (text/plain, inline)]
Hi,

based on Bastian's comments here and a clarification on IRC (thanks!), I
would like to propose the attached patch.
It implements the following behaviour
CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST
 --> added to xen0Kernels
CONFIG_XEN + CONFIG_PARAVIRT
 --> kept in kernel list
CONFIG_XEN + no CONFIG_PARAVIRT
 --> removed from kernel list
     (domU capable, but not bootable standalone)
no CONFIG_XEN
 --> kept in kernel list

For the Debian (most of etch and lenny for i386 and amd64) kernels,
the valid config flags are

config-2.6.18-6-486
config-2.6.18-6-686
config-2.6.18-6-686-bigmem
config-2.6.18-6-amd64
config-2.6.18-6-k7
config-2.6.18-6-vserver-686
config-2.6.18-6-vserver-amd64
config-2.6.18-6-vserver-k7
config-2.6.18-6-xen-686 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST
config-2.6.18-6-xen-amd64 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST
config-2.6.18-6-xen-vserver-686 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST
config-2.6.18-6-xen-vserver-amd64 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST
config-2.6.26-1-486 CONFIG_PARAVIRT
config-2.6.26-1-686 CONFIG_PARAVIRT
config-2.6.26-1-686-bigmem CONFIG_XEN CONFIG_PARAVIRT
config-2.6.26-1-amd64 CONFIG_PARAVIRT
config-2.6.26-1-openvz-686 CONFIG_XEN CONFIG_PARAVIRT
config-2.6.26-1-openvz-amd64 CONFIG_PARAVIRT
config-2.6.26-1-vserver-686 CONFIG_PARAVIRT
config-2.6.26-1-vserver-686-bigmem CONFIG_XEN CONFIG_PARAVIRT
config-2.6.26-1-vserver-amd64 CONFIG_PARAVIRT
config-2.6.26-1-xen-686 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST
config-2.6.26-1-xen-amd64 CONFIG_XEN CONFIG_XEN_PRIVILEGED_GUEST

so we end up with:

bootable with xen kernel
 - 2.6.26-1-xen-amd64
 - 2.6.26-1-xen-686
 - 2.6.18-6-xen-vserver-amd64
 - 2.6.18-6-xen-vserver-686
 - 2.6.18-6-xen-amd64
 - 2.6.18-6-xen-686
bootable standalone
 - 2.6.26-1-vserver-686-bigmem
 - 2.6.26-1-vserver-amd64
 - 2.6.26-1-vserver-686
 - 2.6.26-1-openvz-amd64
 - 2.6.26-1-openvz-686
 - 2.6.26-1-686-bigmem
 - 2.6.26-1-amd64
 - 2.6.26-1-686
 - 2.6.26-1-486
 - 2.6.18-6-vserver-k7
 - 2.6.18-6-vserver-amd64
 - 2.6.18-6-vserver-686
 - 2.6.18-6-686-bigmem
 - 2.6.18-6-k7
 - 2.6.18-6-amd64
 - 2.6.18-6-686
 - 2.6.18-6-486

I have also consolidated the detection and stuff to make use of the
sorted kernel list and postprocess that.
Even though the diff contains a changelog snippet, I would prefer to
have Bastian OK it and also happily leave uploading to the grub
maintainers, even though I could also NMU (e.g. when I get bored waiting
or it actually helps...).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/
[grub.500336.xen-detection.diff (text/x-patch, inline)]
diff -u grub-0.97/debian/update-grub grub-0.97/debian/update-grub
--- grub-0.97/debian/update-grub
+++ grub-0.97/debian/update-grub
@@ -748,58 +748,6 @@
        echo "none found, skipping ..." >&2
 fi
 
-xen0Kernels=""
-# First old style non-CONFIG_PARAVIRT kernels with xen0 support.
-for ver in `grep -l CONFIG_XEN=y /boot/config* | sed -e s%/boot/config-%%`; do
-  if ! grep -q CONFIG_XEN_PRIVILEGED_GUEST=y /boot/config-$ver ; then
-      continue
-  fi
-  # ver is a kernel version
-  kern="/boot/vmlinuz-$ver"
-  if [ -r $kern ] ; then
-       newerKernels=""
-       for i in $xen0Kernels ; do
-                res=$(CompareVersions "$kern" "$i")
-                if [ "$kern" != "" ] && [ "$res" -gt 0 ] ; then
-                        newerKernels="$newerKernels $kern $i"
-                        kern=""
-                else
-                        newerKernels="$newerKernels $i"
-                fi
-        done
-        if [ "$kern" != "" ] ; then
-                newerKernels="$newerKernels $kern"
-        fi
-        xen0Kernels="$newerKernels"
-    fi
-done
-
-# Second new style CONFIG_PARAVIRT kernels with xen support. There is
-# no distinction between xen0 and xenU in these kernels.
-for ver in `grep -l CONFIG_PARAVIRT=y /boot/config* | sed -e s%/boot/config-%%`; do
-  if ! grep -q CONFIG_XEN=y /boot/config-$ver ; then
-      continue
-  fi
-  # ver is a kernel version
-  kern="/boot/vmlinuz-$ver"
-  if [ -r $kern ] ; then
-       newerKernels=""
-       for i in $xen0Kernels ; do
-                res=$(CompareVersions "$kern" "$i")
-                if [ "$kern" != "" ] && [ "$res" -gt 0 ] ; then
-                        newerKernels="$newerKernels $kern $i"
-                        kern=""
-                else
-                        newerKernels="$newerKernels $i"
-                fi
-        done
-        if [ "$kern" != "" ] ; then
-                newerKernels="$newerKernels $kern"
-        fi
-        xen0Kernels="$newerKernels"
-    fi
-done
-
 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
         kern="/boot/$kern"
@@ -819,6 +767,39 @@
 	sortedKernels="$newerKernels"
 done
 
+# Check the sorted kernels for Xen-capable images
+# Bastian Blank explains in #500336:
+# - CONFIG_XEN is set for any Xen capable image.
+# - CONFIG_PARAVIRT is set for the images which can do both.
+# - CONFIG_XEN_PRIVILEGED_GUEST is currently set for anything which can be
+#   booted via a hypervisor.  
+# So images with CONFIG_XEN and no CONFIG_PARAVIRT must not show up as
+# normal bootable.
+#
+# So: CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST
+#     --> dom0-capable
+#     CONFIG_XEN + CONFIG_PARAVIRT
+#     --> domU capabable that can be booted without Xen as well
+#     CONFIG_XEN + NO CONFIG_PARAVIRT
+#     --> domU capable, but must not show up in grub
+newSortedKernels=""
+xen0Kernels=""
+for kern in $sortedKernels ; do
+	kernCfg=$(echo "$kern" | sed 's,/vmlinuz-,/config-,')
+	if grep -q CONFIG_XEN=y "$kernCfg" ; then
+		if grep -q CONFIG_PARAVIRT=y "$kernCfg" ; then
+			newSortedKernels="$newSortedKernels $kern"
+		fi
+		if grep -q CONFIG_XEN_PRIVILEGED_GUEST=y "$kernCfg" ; then
+			xen0Kernels="$xen0Kernels $kern"
+		fi
+	else
+		newSortedKernels="$newSortedKernels $kern"
+	fi
+	
+done
+sortedKernels="$newSortedKernels"
+
 if test -f "/boot/vmlinuz.old" ; then
 	sortedKernels="/boot/vmlinuz.old $sortedKernels"
 fi
diff -u grub-0.97/debian/changelog grub-0.97/debian/changelog
--- grub-0.97/debian/changelog
+++ grub-0.97/debian/changelog
@@ -1,3 +1,10 @@
+grub (0.97-47.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix xen-capability detection. Closes: #500336
+
+ -- Thomas Viehmann <tv@beamnet.de>  Fri, 17 Oct 2008 23:27:55 +0200
+
 grub (0.97-47) unstable; urgency=high
 
   * update-grub: Send grub-probe stderr output to /dev/null.  (Closes: #495909)

Tags added: patch Request was from Thomas Viehmann <tv@beamnet.de> to control@bugs.debian.org. (Fri, 17 Oct 2008 22:30:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Sat, 18 Oct 2008 13:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bastian Blank <waldi@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Sat, 18 Oct 2008 13:12:02 GMT) Full text and rfc822 format available.

Message #32 received at 500336@bugs.debian.org (full text, mbox):

From: Bastian Blank <waldi@debian.org>
To: Thomas Viehmann <tv@beamnet.de>
Cc: 500336@bugs.debian.org
Subject: Re: patch for grub detection
Date: Sat, 18 Oct 2008 15:08:57 +0200
On Fri, Oct 17, 2008 at 11:40:07PM +0200, Thomas Viehmann wrote:
> based on Bastian's comments here and a clarification on IRC (thanks!), I
> would like to propose the attached patch.

Looks okay.

Bastian




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Mon, 20 Oct 2008 06:54:02 GMT) Full text and rfc822 format available.

Message #35 received at 500336@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org
Cc: Bastian Blank <waldi@debian.org>, Ian Campbell <ijc@hellion.org.uk>
Subject: Re: Bug#500336: patch for grub detection
Date: Mon, 20 Oct 2008 08:52:32 +0200
On Fri, Oct 17, 2008 at 11:40:07PM +0200, Thomas Viehmann wrote:
> Hi,
> 
> based on Bastian's comments here and a clarification on IRC (thanks!), I
> would like to propose the attached patch.

I understand that Bastian knows what he's doing, but nevertheless I'd like
this to be okayed by Ian (CCed) before we apply it, since the current
behaviour was stablished by him.

Also, I'd like to know if we should adjust GRUB 2 accordingly (its current
policy is not to special-case Xen images).

Thanks!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Mon, 20 Oct 2008 08:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 20 Oct 2008 08:12:02 GMT) Full text and rfc822 format available.

Message #40 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Robert Millan <rmh@aybabtu.com>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Mon, 20 Oct 2008 09:09:04 +0100
[Message part 1 (text/plain, inline)]
On Mon, 2008-10-20 at 08:52 +0200, Robert Millan wrote:
> On Fri, Oct 17, 2008 at 11:40:07PM +0200, Thomas Viehmann wrote:
> > Hi,
> > 
> > based on Bastian's comments here and a clarification on IRC (thanks!), I
> > would like to propose the attached patch.
> 
> I understand that Bastian knows what he's doing, but nevertheless I'd like
> this to be okayed by Ian (CCed) before we apply it, since the current
> behaviour was stablished by him.

My only concern would be the behaviour when running in a domU. I haven't
looked very closely at the patch yet but a comment says
+#     CONFIG_XEN + NO CONFIG_PARAVIRT
+#     --> domU capable, but must not show up in grub

which sounds like menu.lst in a guest domain will end up omitting the
non-paravirt Xen kernels. These entries are needed to allow booting via
pygrub. Lenny does include such images now due to the use of the SuSE
patch which makes e.g. 2.6.26-1-xen-amd64 look this way. People
upgrading a domU from Etch will likely end up with this style image
installed as well.

Unfortunately I don't think it is so easy to distinguish between the
domU and dom0 use cases, especially if you consider people provisioning
a domU inside a chroot from dom0 before launching it as a guest (a case
which is broken in Etch due to the checks of /proc/xen/capabilities).
Perhaps one could key off the presence of /boot/xen.gz? IOW 
        CONFIG_XEN + no CONFIG_PARAVIRT + /boot/xen.gz present
         --> removed from kernel list
             (domU capable, but not bootable standalone)
        CONFIG_XEN + no CONFIG_PARAVIRT + /boot/xen.gz not present
        --> kept in kernel list
             (domU capable, and no xen.gz so not dom0?)
Seems nasty though.

In the face of uncertainty I think I would rather err on the side of
including kernels in configurations which cannot boot rather than
excluding ones which can since the workarounds are respectively "don't
boot/install it then" vs "manually add and maintain a stanza for that
kernel".

Ian.

> 
> Also, I'd like to know if we should adjust GRUB 2 accordingly (its current
> policy is not to special-case Xen images).
> 
> Thanks!
> 
-- 
Ian Campbell

No character, however upright, is a match for constantly reiterated attacks,
however false.
		-- Alexander Hamilton
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Mon, 20 Oct 2008 19:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Viehmann <tv@beamnet.de>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Mon, 20 Oct 2008 19:21:05 GMT) Full text and rfc822 format available.

Message #45 received at 500336@bugs.debian.org (full text, mbox):

From: Thomas Viehmann <tv@beamnet.de>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Mon, 20 Oct 2008 21:18:00 +0200
Hi,

Ian Campbell wrote:
> My only concern would be the behaviour when running in a domU. I haven't
> looked very closely at the patch yet but a comment says
> +#     CONFIG_XEN + NO CONFIG_PARAVIRT
> +#     --> domU capable, but must not show up in grub
> 
> which sounds like menu.lst in a guest domain will end up omitting the
> non-paravirt Xen kernels. These entries are needed to allow booting via
> pygrub. Lenny does include such images now due to the use of the SuSE
> patch which makes e.g. 2.6.26-1-xen-amd64 look this way. People
> upgrading a domU from Etch will likely end up with this style image
> installed as well.

No, 2.6.26-1-xen-amd64/lenny is actually capable of both. So the problem
would bite people upgrading grub but not the kernel.
Ideally, one would add way to collect domU-only kernels (with some
commented-out-magic or in a separate pygrub.menu.lst) for a patched pygrub.

> Unfortunately I don't think it is so easy to distinguish between the
> domU and dom0 use cases, especially if you consider people provisioning
> a domU inside a chroot from dom0 before launching it as a guest (a case
> which is broken in Etch due to the checks of /proc/xen/capabilities).
> Perhaps one could key off the presence of /boot/xen.gz? IOW 
>         CONFIG_XEN + no CONFIG_PARAVIRT + /boot/xen.gz present
>          --> removed from kernel list
>              (domU capable, but not bootable standalone)
>         CONFIG_XEN + no CONFIG_PARAVIRT + /boot/xen.gz not present
>         --> kept in kernel list
>              (domU capable, and no xen.gz so not dom0?)
> Seems nasty though.
Indeed. Patching pygrub sounds better to me.

> In the face of uncertainty I think I would rather err on the side of
> including kernels in configurations which cannot boot rather than
> excluding ones which can since the workarounds are respectively "don't
> boot/install it then" vs "manually add and maintain a stanza for that
> kernel".
To be honest, having a non-virtual (i.e. native or dom0) boot fail seems
worse than having a virtual machine fail to boot to me because the
former is inherently more opaque from a distance (yeah, serial consoles
work, but suck).

Maybe you (Ian) and Bastian could comment on whether they'd accept the
above as a solution?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Tue, 21 Oct 2008 07:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Tue, 21 Oct 2008 07:21:04 GMT) Full text and rfc822 format available.

Message #50 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Thomas Viehmann <tv@beamnet.de>
Cc: 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Tue, 21 Oct 2008 08:17:18 +0100
[Message part 1 (text/plain, inline)]
On Mon, 2008-10-20 at 21:18 +0200, Thomas Viehmann wrote:
> Hi,
> 
> Ian Campbell wrote:
> > My only concern would be the behaviour when running in a domU. I haven't
> > looked very closely at the patch yet but a comment says
> > +#     CONFIG_XEN + NO CONFIG_PARAVIRT
> > +#     --> domU capable, but must not show up in grub
> > 
> > which sounds like menu.lst in a guest domain will end up omitting the
> > non-paravirt Xen kernels. These entries are needed to allow booting via
> > pygrub. Lenny does include such images now due to the use of the SuSE
> > patch which makes e.g. 2.6.26-1-xen-amd64 look this way. People
> > upgrading a domU from Etch will likely end up with this style image
> > installed as well.
> 
> No, 2.6.26-1-xen-amd64/lenny is actually capable of both.

Both what?

> So the problem would bite people upgrading grub but not the kernel.

Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
version of grub would end up with a menu.lst which did not contain this
kernel, which would be incorrect.

> Ideally, one would add way to collect domU-only kernels (with some
> commented-out-magic or in a separate pygrub.menu.lst) for a patched pygrub.

I think in an earlier version of the patch which became the current
stuff had a magic variable thing. I think I'd be happy with a
commented-out-magic IFF there is absolutely no way to make it work by
default.

> To be honest, having a non-virtual (i.e. native or dom0) boot fail
> seems worse than having a virtual machine fail to boot to me because
> the former is inherently more opaque from a distance (yeah, serial
> consoles work, but suck).

If you are the admin of a domU with no access rights to dom0 (common
with hosting providers) then I think the two are equivalent.

Ian.
-- 
Ian Campbell

Some men are discovered; others are found out.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Wed, 29 Oct 2008 17:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 29 Oct 2008 17:03:06 GMT) Full text and rfc822 format available.

Message #55 received at 500336@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Wed, 29 Oct 2008 17:56:01 +0100
Hi,

we need to decide on a fix for this RC bug and get a new grub uploaded.
So lets restart the discussion.

On Tue, 21 Oct 2008, Ian Campbell wrote:
> On Mon, 2008-10-20 at 21:18 +0200, Thomas Viehmann wrote:
> > Hi,
> > 
> > Ian Campbell wrote:
> > > My only concern would be the behaviour when running in a domU. I haven't
> > > looked very closely at the patch yet but a comment says
> > > +#     CONFIG_XEN + NO CONFIG_PARAVIRT
> > > +#     --> domU capable, but must not show up in grub
> > > 
> > > which sounds like menu.lst in a guest domain will end up omitting the
> > > non-paravirt Xen kernels. These entries are needed to allow booting via
> > > pygrub. Lenny does include such images now due to the use of the SuSE
> > > patch which makes e.g. 2.6.26-1-xen-amd64 look this way. People
> > > upgrading a domU from Etch will likely end up with this style image
> > > installed as well.
> > 
> > No, 2.6.26-1-xen-amd64/lenny is actually capable of both.
> 
> Both what?

Both booting in dom0 and in domU AFAIK.

> > So the problem would bite people upgrading grub but not the kernel.
> 
> Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
> version of grub would end up with a menu.lst which did not contain this
> kernel, which would be incorrect.

But this is only a problem for pygrub users and it looks like pygrub is
not even packaged for Debian. 

Does this fix constitute a regression compared to etch ?
Does this fix constitute a regression compared to what's in lenny now ?

> > Ideally, one would add way to collect domU-only kernels (with some
> > commented-out-magic or in a separate pygrub.menu.lst) for a patched pygrub.
> 
> I think in an earlier version of the patch which became the current
> stuff had a magic variable thing. I think I'd be happy with a
> commented-out-magic IFF there is absolutely no way to make it work by
> default.

Are you referring to something like what has been suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479478 ?

In any case, Ian, we need to go forward and if the patch proposed by
Thomas doesn't satisfy you, can you prepare an alternative patch
that would address your concerns ?

I wonder if we have a reliable way to know that the target system
is a domU when we install it with d-i. After all, from what I understand
that's the main problem to solve to be able to special-case the kernels
that can boot in a domU only.

And I agree with Thomas that including a non-bootable kernel in menu.lst
is bad. That's why this bug is RC… so if we have to choose beetwen missing
some domU kernels in domU and having unbootable kernels in other
situation, we should choose the former.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Wed, 29 Oct 2008 17:54:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Wed, 29 Oct 2008 17:54:18 GMT) Full text and rfc822 format available.

Message #60 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Wed, 29 Oct 2008 17:43:16 +0000
On Wed, 2008-10-29 at 17:56 +0100, Raphael Hertzog wrote:
> Hi,
> 
> we need to decide on a fix for this RC bug and get a new grub uploaded.
> So lets restart the discussion.
> 
> On Tue, 21 Oct 2008, Ian Campbell wrote:
> > On Mon, 2008-10-20 at 21:18 +0200, Thomas Viehmann wrote:
> > > Hi,
> > > 
> > > Ian Campbell wrote:
> > > > My only concern would be the behaviour when running in a domU. I haven't
> > > > looked very closely at the patch yet but a comment says
> > > > +#     CONFIG_XEN + NO CONFIG_PARAVIRT
> > > > +#     --> domU capable, but must not show up in grub
> > > > 
> > > > which sounds like menu.lst in a guest domain will end up omitting the
> > > > non-paravirt Xen kernels. These entries are needed to allow booting via
> > > > pygrub. Lenny does include such images now due to the use of the SuSE
> > > > patch which makes e.g. 2.6.26-1-xen-amd64 look this way. People
> > > > upgrading a domU from Etch will likely end up with this style image
> > > > installed as well.
> > > 
> > > No, 2.6.26-1-xen-amd64/lenny is actually capable of both.
> > 
> > Both what?
> 
> Both booting in dom0 and in domU AFAIK.

OK, yes this is true. I thought maybe he meant native vs on Xen which
isn't (using "both" in a situation with three option is a little
confusing ;-)) or maybe something else since the quoted paragraph
doesn't mention dom0 at all...

> > > So the problem would bite people upgrading grub but not the kernel.
> > 
> > Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
> > version of grub would end up with a menu.lst which did not contain this
> > kernel, which would be incorrect.
> 
> But this is only a problem for pygrub users and it looks like pygrub is
> not even packaged for Debian. 

It's just part of Xen:

$ dpkg -S /usr/lib/xen-3.2-1/bin/pygrub 
xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub

> Does this fix constitute a regression compared to etch ?
> Does this fix constitute a regression compared to what's in lenny now ?

I think in both cases it depends on whether you are in the "I've got a
kernel entry I can't boot" camp or the "I've not got a kernel entry I
could boot" camp.

> > > Ideally, one would add way to collect domU-only kernels (with some
> > > commented-out-magic or in a separate pygrub.menu.lst) for a patched pygrub.
> > 
> > I think in an earlier version of the patch which became the current
> > stuff had a magic variable thing. I think I'd be happy with a
> > commented-out-magic IFF there is absolutely no way to make it work by
> > default.
> 
> Are you referring to something like what has been suggested in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479478 ?

Yes something like that.

I previously had concerns because /proc/xen doesn't exist on pv ops
kernels, but since we would not go down this path on a pv ops kernel
this doesn't even make sense to me anymore, I'm not sure what I was
thinking... Perhaps I was considering the future existence of pvops
domain 0 kernels but since they don't yet exist and probably will
have /proc/xen lets not worry.

> In any case, Ian, we need to go forward and if the patch proposed by
> Thomas doesn't satisfy you, can you prepare an alternative patch
> that would address your concerns ?
> 
> I wonder if we have a reliable way to know that the target system
> is a domU when we install it with d-i. After all, from what I understand
> that's the main problem to solve to be able to special-case the kernels
> that can boot in a domU only.

Under 32 bit d-i will install a 686-bigmem kernel (i.e. a paravirt ops
one) and the current and patched update-grub would do the right thing
since CONFIG_XEN+CONFIG_PARAVIRT => update-grub will always make a
native style entry.

If a user manually installs the non-paravirt -xen-686 kernel in a domU
(which is not unlikely, even if I think its unnecessary...):
      * currently it will work, since there is no special casing =>
        create a native style entry.
      * with the proposed patch it will break. Since CONFIG_XEN + NO
        CONFIG_PARAVIRT => No grub entry.
      * with something like 479478 incorporated into the CONFIG_XEN + NO
        CONFIG_PARAVIRT case then it should work since domU=1 => Create
        a grub entry.

Since there has historically been no d-i support for Xen (and still
isn't for 64 bit) some users will be using constructing a domU using
tools such as xen-tools or debootstrap (I'm sure there are others). In
that case I'd expect them to get the -xen-686 image since the paravirt
ops stuff hasn't propagated to all those tools yet.

Similarly people upgrading a domU from Etch would get a -xen-686 image
since that is what they have now.

> And I agree with Thomas that including a non-bootable kernel in menu.lst
> is bad. That's why this bug is RC… so if we have to choose beetwen missing
> some domU kernels in domU and having unbootable kernels in other
> situation, we should choose the former.

I'm not so sure I agree (there are plenty of ways to end up with invalid
grub configurations surely, installing pae on a non-pae machine for
example) but I think given the above we have a solution which works for
both cases anyway, so lets ignore that little disagreement...

Ian.
-- 
Ian Campbell
Current Noise: The Meads Of Asphodel - 80 Grains Of Sand

Save the bales!





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Wed, 29 Oct 2008 18:18:07 GMT) Full text and rfc822 format available.

Message #63 received at 500336@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>, 500336@bugs.debian.org
Cc: Ian Campbell <ijc@hellion.org.uk>, Thomas Viehmann <tv@beamnet.de>, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Wed, 29 Oct 2008 19:02:10 +0100
tags 500336 - patch
# still being discussed
thanks

On Wed, Oct 29, 2008 at 05:56:01PM +0100, Raphael Hertzog wrote:
> 
> I wonder if we have a reliable way to know that the target system
> is a domU when we install it with d-i. After all, from what I understand
> that's the main problem to solve to be able to special-case the kernels
> that can boot in a domU only.
> 
> And I agree with Thomas that including a non-bootable kernel in menu.lst
> is bad. That's why this bug is RC… so if we have to choose beetwen missing
> some domU kernels in domU and having unbootable kernels in other
> situation, we should choose the former.

Based on Ian's advice, we stablished GRUB 2's policy in upstream on not
making any distinction and including all detected Linux images by default.
If I understood correctly, with Xen support being gradually merged into
mainline, false positives are only an issue for older versions of Linux;
we concluded that it would be acceptable to list all of them for the sake
of avoiding the complexity.

GRUB Legacy already has logic to attempt making the distinction, and there's
no point in removing it, but then again we're already considering this a
neglectable problem when it comes to GRUB 2.

Because of this, unless there's something I missed that you would like to
mention, I'm inclined to lower the severity to "important" and not consider
this a release critical issue.  If you reach a consensus on what needs to
be done, though, I'd still welcome having this fix in Lenny.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Tags removed: patch Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. (Wed, 29 Oct 2008 18:18:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 30 Oct 2008 10:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 30 Oct 2008 10:03:07 GMT) Full text and rfc822 format available.

Message #70 received at 500336@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 30 Oct 2008 10:57:39 +0100
On Wed, 29 Oct 2008, Ian Campbell wrote:
> > > > So the problem would bite people upgrading grub but not the kernel.
> > > 
> > > Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
> > > version of grub would end up with a menu.lst which did not contain this
> > > kernel, which would be incorrect.
> > 
> > But this is only a problem for pygrub users and it looks like pygrub is
> > not even packaged for Debian. 
> 
> It's just part of Xen:
> 
> $ dpkg -S /usr/lib/xen-3.2-1/bin/pygrub 
> xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub

Hu, okay. I have been using Xen on multiple (etch) machines and never used
that. I always boot a kernel stored on the dom0.

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479478 ?
> 
> Yes something like that.
> 
> I previously had concerns because /proc/xen doesn't exist on pv ops
> kernels, but since we would not go down this path on a pv ops kernel
> this doesn't even make sense to me anymore, I'm not sure what I was
> thinking... Perhaps I was considering the future existence of pvops
> domain 0 kernels but since they don't yet exist and probably will
> have /proc/xen lets not worry.

I have troubles following your reasoning here. Are you saying that
the test on /proc/xen/capabilities shown above is enough and should be
reinstated for the sake of deciding if we're on a domU ?

Can you provide a patch for this that would also include Thomas's initial
patch ?

> If a user manually installs the non-paravirt -xen-686 kernel in a domU
> (which is not unlikely, even if I think its unnecessary...):

Well, I only have the linux-modules-*-xen-686 part in all my domU and not
the kernel itself.

> Since there has historically been no d-i support for Xen (and still
> isn't for 64 bit) some users will be using constructing a domU using
> tools such as xen-tools or debootstrap (I'm sure there are others). In
> that case I'd expect them to get the -xen-686 image since the paravirt
> ops stuff hasn't propagated to all those tools yet.

Neither debootstrap nor xen-tools (at least the etch version) do install
a kernel AFAIK.

> I'm not so sure I agree (there are plenty of ways to end up with invalid
> grub configurations surely, installing pae on a non-pae machine for
> example) but I think given the above we have a solution which works for
> both cases anyway, so lets ignore that little disagreement...

I'm fine with this, I just want to get this bug fixed so that we can
release lenny. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 30 Oct 2008 10:54:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 30 Oct 2008 10:54:09 GMT) Full text and rfc822 format available.

Message #75 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 30 Oct 2008 10:35:03 +0000
On Thu, 2008-10-30 at 10:57 +0100, Raphael Hertzog wrote:
> On Wed, 29 Oct 2008, Ian Campbell wrote:
> > > > > So the problem would bite people upgrading grub but not the kernel.
> > > > 
> > > > Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
> > > > version of grub would end up with a menu.lst which did not contain this
> > > > kernel, which would be incorrect.
> > > 
> > > But this is only a problem for pygrub users and it looks like pygrub is
> > > not even packaged for Debian. 
> > 
> > It's just part of Xen:
> > 
> > $ dpkg -S /usr/lib/xen-3.2-1/bin/pygrub 
> > xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub
> 
> Hu, okay. I have been using Xen on multiple (etch) machines and never used
> that. I always boot a kernel stored on the dom0.

That's the other alternative and both have their
advantages/disadvantages.

I prefer the pygrub method myself since it keeps all of domU's files
inside the domU itself, I find it particularly useful when dom0 isn't
Debian or when the domU admin doesn't have rights in dom0, for example.

> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479478 ?
> > 
> > Yes something like that.
> > 
> > I previously had concerns because /proc/xen doesn't exist on pv ops
> > kernels, but since we would not go down this path on a pv ops kernel
> > this doesn't even make sense to me anymore, I'm not sure what I was
> > thinking... Perhaps I was considering the future existence of pvops
> > domain 0 kernels but since they don't yet exist and probably will
> > have /proc/xen lets not worry.
> 
> I have troubles following your reasoning here. Are you saying that
> the test on /proc/xen/capabilities shown above is enough and should be
> reinstated for the sake of deciding if we're on a domU ?

I remembered my concern.

Keying the behaviour of update grub on the contents
of /proc/xen/capabilities means that the menu.lst which gets generated
will depend on the currently running kernel (since pv ops kernels have
no /proc/xen/cap.. at the moment).

This means that if I am running a pv ops kernel and I install a
non-pvops kernel for whatever reason then my menu.lst will omit it.

Or, even worse, if I have a menu.lst which correctly lists both types of
kernel and I happen to re-run update-grub whilst running a pvops kernel
then a bunch of my working and correct stanzas will be removed.

Or, if I create a domU filesystem using debootstrap or a similar tool
which does the initial construction in a chroot
then /proc/xen/capabilities will look like a dom0 and update-grub will
again do the wrong thing.

Now having a configuration variable "indomu=auto|true|false" allows this
to be worked around but the default would be auto which still has all
the above problems.

I'd be inclined to go with Robert's suggestion of reducing the severity
and not considering the bug RC, the complexity of all these special
cases just aren't worth it, especially since the situation will resolve
itself as pvops becomes the only option.

IMHO there's nothing magic about a Xen kernel which means it should be
treated any different to installing e.g. a PAE kernel on a non-PAE
capable system or otherwise making a mess of your bootloader config or
initrd etc. If you boot one by mistake then simply reboot and choose a
correct kernel.

> > If a user manually installs the non-paravirt -xen-686 kernel in a domU
> > (which is not unlikely, even if I think its unnecessary...):
> 
> Well, I only have the linux-modules-*-xen-686 part in all my domU and not
> the kernel itself.

That's because you don't use pygrub...

> > Since there has historically been no d-i support for Xen (and still
> > isn't for 64 bit) some users will be using constructing a domU using
> > tools such as xen-tools or debootstrap (I'm sure there are others). In
> > that case I'd expect them to get the -xen-686 image since the paravirt
> > ops stuff hasn't propagated to all those tools yet.
> 
> Neither debootstrap nor xen-tools (at least the etch version) do install
> a kernel AFAIK.

OK, in which case the user must install a kernel after running whichever
tool (if they want to use pygrub) and in that case they are reasonably
likely to choose the -xen-686 image due to the name, even though
-686-bigmem would be preferred.

Ian.
-- 
Ian Campbell
Current Noise: Motörhead - Iron Horse

union, n.:
	A dues-paying club workers wield to strike management.





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 30 Oct 2008 15:48:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 30 Oct 2008 15:48:22 GMT) Full text and rfc822 format available.

Message #80 received at 500336@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 30 Oct 2008 16:45:27 +0100
On Thu, 30 Oct 2008, Ian Campbell wrote:
> This means that if I am running a pv ops kernel and I install a
> non-pvops kernel for whatever reason then my menu.lst will omit it.

Sure. 

Let's come back to the root of this bug report, the problem is that
2.6.26-1-686-bigmem has CONFIG_XEN and CONFIG_PARAVIRT and is considered
to be a suitable dom0 kernel when in fact it's not.

They are added to xen0Kernels by the second loop:
# Second new style CONFIG_PARAVIRT kernels with xen support. There is
# no distinction between xen0 and xenU in these kernels.
for ver in `grep -l CONFIG_PARAVIRT=y /boot/config* | sed -e s%/boot/config-%%`; do
  if ! grep -q CONFIG_XEN=y /boot/config-$ver ; then
      continue
  fi
[...]

What's the reasoning behind this loop ? All the suitable kernels are already selected
by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.

Can't we simply drop this loop and be done with it ? What do I miss ?

All the kernels are still listed individually but that category of kernel is no
more combined with the hypervisor if it's available.

We at least reduce the number of bad combinations without dropping any good
combination if I trust the table given in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 30 Oct 2008 16:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 30 Oct 2008 16:00:03 GMT) Full text and rfc822 format available.

Message #85 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 30 Oct 2008 15:57:30 +0000
On Thu, 2008-10-30 at 16:45 +0100, Raphael Hertzog wrote:
> On Thu, 30 Oct 2008, Ian Campbell wrote:
> > This means that if I am running a pv ops kernel and I install a
> > non-pvops kernel for whatever reason then my menu.lst will omit it.
> 
> Sure. 
> 
> Let's come back to the root of this bug report, the problem is that
> 2.6.26-1-686-bigmem has CONFIG_XEN and CONFIG_PARAVIRT and is considered
> to be a suitable dom0 kernel when in fact it's not.
> 
> They are added to xen0Kernels by the second loop:
> # Second new style CONFIG_PARAVIRT kernels with xen support. There is
> # no distinction between xen0 and xenU in these kernels.
> for ver in `grep -l CONFIG_PARAVIRT=y /boot/config* | sed -e s%/boot/config-%%`; do
>   if ! grep -q CONFIG_XEN=y /boot/config-$ver ; then
>       continue
>   fi
> [...]
> 
> What's the reasoning behind this loop ? All the suitable kernels are already selected
> by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.
> 
> Can't we simply drop this loop and be done with it ? What do I miss ?

Current paravirt ops kernels cannot be booted as a dom0 but future ones
will be. Currently there is no way to tell them apart, there may or may
not be a variable similar to CONFIG_XEN_PRIVILEGED_GUEST for those
kernels when dom0 support goes upstream. However we have no way of
knowing what will happen here.

(I may have been mistakenly thought we were discussing that a "native
style" entry was being created for the -xen-686 kernel (in addition to
one which specified a hypervisor).)

> All the kernels are still listed individually but that category of kernel is no
> more combined with the hypervisor if it's available.
> 
> We at least reduce the number of bad combinations without dropping any good
> combination if I trust the table given in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25

But this table *does* drop a good combination, which is a CONFIG_XEN +
no CONFIG_PARAVIRT when used inside a domU.

Ian.

-- 
Ian Campbell
Current Noise: Sabbat - The Clerical Conspiracy (Live)

You're almost as happy as you think you are.





Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 30 Oct 2008 17:54:54 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 30 Oct 2008 17:54:55 GMT) Full text and rfc822 format available.

Message #90 received at 500336@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 30 Oct 2008 18:50:10 +0100
[Message part 1 (text/plain, inline)]
tag 500336 + patch
thanks

On Thu, 30 Oct 2008, Ian Campbell wrote:
> > What's the reasoning behind this loop ? All the suitable kernels are already selected
> > by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.
> > 
> > Can't we simply drop this loop and be done with it ? What do I miss ?
> 
> Current paravirt ops kernels cannot be booted as a dom0 but future ones
> will be. Currently there is no way to tell them apart, there may or may
> not be a variable similar to CONFIG_XEN_PRIVILEGED_GUEST for those
> kernels when dom0 support goes upstream. However we have no way of
> knowing what will happen here.

Why are we trying to guess the future here ? We want something working for
lenny now and we'll fix that for squeeze when it has been merged upstream.

> (I may have been mistakenly thought we were discussing that a "native
> style" entry was being created for the -xen-686 kernel (in addition to
> one which specified a hypervisor).)

That is also the case (since we don't drop anything out of
sortedKernel) but it's not what this bug is reporting. Furthermore entries
for the hypervisor tend to be first and thus any bad first entry is worse
than any bad entry that appears later in the list.

> > All the kernels are still listed individually but that category of kernel is no
> > more combined with the hypervisor if it's available.
> > 
> > We at least reduce the number of bad combinations without dropping any good
> > combination if I trust the table given in
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25
> 
> But this table *does* drop a good combination, which is a CONFIG_XEN +
> no CONFIG_PARAVIRT when used inside a domU.

The table shows the CONFIG combinations in all official Debian kernels
that we care about, it doesn't drop anything. Thomas's patch drop those
combinations from sortedKernel however.

I propose to not use Thomas patch but to remove the code that tries to
deal with future kernel that do not exist yet and to be done with that
bug.

Please find the patch attached. It works here at least.

(Note: it looks like that grub-pc's update-grub doesn't deal at all with Xen
yet…)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[patch (text/plain, attachment)]

Tags added: patch Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 30 Oct 2008 17:55:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Fri, 31 Oct 2008 08:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Fri, 31 Oct 2008 08:57:02 GMT) Full text and rfc822 format available.

Message #97 received at 500336@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Fri, 31 Oct 2008 08:55:57 +0000
[Message part 1 (text/plain, inline)]
On Thu, 2008-10-30 at 18:50 +0100, Raphael Hertzog wrote:
> tag 500336 + patch
> thanks
> 
> On Thu, 30 Oct 2008, Ian Campbell wrote:
> > > What's the reasoning behind this loop ? All the suitable kernels are already selected
> > > by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.
> > > 
> > > Can't we simply drop this loop and be done with it ? What do I miss ?
> > 
> > Current paravirt ops kernels cannot be booted as a dom0 but future ones
> > will be. Currently there is no way to tell them apart, there may or may
> > not be a variable similar to CONFIG_XEN_PRIVILEGED_GUEST for those
> > kernels when dom0 support goes upstream. However we have no way of
> > knowing what will happen here.
> 
> Why are we trying to guess the future here ? We want something working for
> lenny now and we'll fix that for squeeze when it has been merged upstream.

At the time of the original patch the dom0 support seemed quite
imminent. As it currently stands patches exist but have missed the
2.6.28 merge window so it is likely to be 2.6.29 before they are
available (i.e. they are still "quite imminent" ;-) ).

However you are right we shouldn't worry about it for getting Lenny out
and I think the right thing to do is for me to ask upstream to use the
CONFIG_XEN_PRIVILEGED_GUEST symbol when they add this support.

> > (I may have been mistakenly thought we were discussing that a "native
> > style" entry was being created for the -xen-686 kernel (in addition to
> > one which specified a hypervisor).)
> 
> That is also the case (since we don't drop anything out of
> sortedKernel) but it's not what this bug is reporting. Furthermore entries
> for the hypervisor tend to be first and thus any bad first entry is worse
> than any bad entry that appears later in the list.
> 
> > > All the kernels are still listed individually but that category of kernel is no
> > > more combined with the hypervisor if it's available.
> > > 
> > > We at least reduce the number of bad combinations without dropping any good
> > > combination if I trust the table given in
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25
> > 
> > But this table *does* drop a good combination, which is a CONFIG_XEN +
> > no CONFIG_PARAVIRT when used inside a domU.
> 
> The table shows the CONFIG combinations in all official Debian kernels
> that we care about, it doesn't drop anything. Thomas's patch drop those
> combinations from sortedKernel however.

The table showed "CONFIG_XEN + no CONFIG_PARAVIRT -> removed from kernel
list" which is exactly what Thomas' patch implemented. It was that
dropping from sortedKernel was what I objected to since it broke domU.

> I propose to not use Thomas patch but to remove the code that tries to
> deal with future kernel that do not exist yet and to be done with that
> bug.
> 
> Please find the patch attached. It works here at least.

I'm happy with it too since it works in domU (no change).

For future paravirt ops dom0 kernels I should try and convince them to
reintroduce the CONFIG_XEN_PRIVILEGED_GUEST symbol which will make the
patches update-grub "just work" (I tested it by hacking /boot/config)

> (Note: it looks like that grub-pc's update-grub doesn't deal at all with Xen
> yet…)

A deliberate upstream policy I believe, according to one of Robert's
previous mails to this bug.

Ian.
-- 
Ian Campbell

#if _FP_W_TYPE_SIZE < 64
#error "Only stud muffins allowed, schmuck."
#endif
		-- linux/arch/sparc64/quad.c
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 06 Nov 2008 18:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>. (Thu, 06 Nov 2008 18:48:03 GMT) Full text and rfc822 format available.

Message #102 received at 500336@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>, Ian Campbell <ijc@hellion.org.uk>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 6 Nov 2008 19:45:09 +0100
On Fri, 31 Oct 2008, Ian Campbell wrote:
> > Please find the patch attached. It works here at least.
> 
> I'm happy with it too since it works in domU (no change).

Several days passed and I saw no reaction from the maintainers.

Robert, can you apply the patch and upload a fixed package to get rid of
2 RC bugs?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Thu, 06 Nov 2008 20:06:02 GMT) Full text and rfc822 format available.

Message #105 received at 500336@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Thomas Viehmann <tv@beamnet.de>, 500336@bugs.debian.org, Bastian Blank <waldi@debian.org>, Ian Campbell <ijc@hellion.org.uk>
Subject: Re: Bug#500336: patch for grub detection
Date: Thu, 6 Nov 2008 21:05:05 +0100
On Thu, Nov 06, 2008 at 07:45:09PM +0100, Raphael Hertzog wrote:
> On Fri, 31 Oct 2008, Ian Campbell wrote:
> > > Please find the patch attached. It works here at least.
> > 
> > I'm happy with it too since it works in domU (no change).
> 
> Several days passed and I saw no reaction from the maintainers.
> 
> Robert, can you apply the patch and upload a fixed package to get rid of
> 2 RC bugs?

Hi,

I'll prepare an upload this weekend.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>:
Bug#500336; Package grub. (Fri, 07 Nov 2008 18:33:05 GMT) Full text and rfc822 format available.

Message #108 received at 500336@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Raphael Hertzog <hertzog@debian.org>, 500336@bugs.debian.org
Cc: Ian Campbell <ijc@hellion.org.uk>, Thomas Viehmann <tv@beamnet.de>, Bastian Blank <waldi@debian.org>
Subject: Re: Bug#500336: patch for grub detection
Date: Fri, 7 Nov 2008 19:31:18 +0100
On Thu, Oct 30, 2008 at 06:50:10PM +0100, Raphael Hertzog wrote:
> 
> Why are we trying to guess the future here ? We want something working for
> lenny now and we'll fix that for squeeze when it has been merged upstream.
> 
> [...]
> 
> I propose to not use Thomas patch but to remove the code that tries to
> deal with future kernel that do not exist yet and to be done with that
> bug.
> 
> Please find the patch attached. It works here at least.

Looks reasonable.  I checked that in.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Tags added: pending Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. (Fri, 07 Nov 2008 18:33:07 GMT) Full text and rfc822 format available.

Reply sent to Robert Millan <rmh@aybabtu.com>:
You have taken responsibility. (Fri, 07 Nov 2008 18:57:08 GMT) Full text and rfc822 format available.

Notification sent to Bastian Blank <waldi@debian.org>:
Bug acknowledged by developer. (Fri, 07 Nov 2008 18:57:08 GMT) Full text and rfc822 format available.

Message #115 received at 500336-close@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: 500336-close@bugs.debian.org
Subject: Bug#500336: fixed in grub 0.97-47lenny1
Date: Fri, 07 Nov 2008 18:47:04 +0000
Source: grub
Source-Version: 0.97-47lenny1

We believe that the bug you reported is fixed in the latest version of
grub, which is due to be installed in the Debian FTP archive:

grub-disk_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-disk_0.97-47lenny1_all.deb
grub-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-doc_0.97-47lenny1_all.deb
grub-legacy-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/grub-legacy-doc_0.97-47lenny1_all.deb
grub_0.97-47lenny1.diff.gz
  to pool/main/g/grub/grub_0.97-47lenny1.diff.gz
grub_0.97-47lenny1.dsc
  to pool/main/g/grub/grub_0.97-47lenny1.dsc
grub_0.97-47lenny1_amd64.deb
  to pool/main/g/grub/grub_0.97-47lenny1_amd64.deb
multiboot-doc_0.97-47lenny1_all.deb
  to pool/main/g/grub/multiboot-doc_0.97-47lenny1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 500336@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Robert Millan <rmh@aybabtu.com> (supplier of updated grub package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri,  7 Nov 2008 19:28:46 +0100
Source: grub
Binary: grub grub-disk grub-doc grub-legacy-doc multiboot-doc
Architecture: source amd64 all
Version: 0.97-47lenny1
Distribution: unstable
Urgency: high
Maintainer: Grub Maintainers <pkg-grub-devel@lists.alioth.debian.org>
Changed-By: Robert Millan <rmh@aybabtu.com>
Description: 
 grub       - GRand Unified Bootloader (Legacy version)
 grub-disk  - GRUB bootable disk image (dummy package)
 grub-doc   - Documentation for GRand Unified Bootloader (dummy package)
 grub-legacy-doc - Documentation for GRUB Legacy
 multiboot-doc - The Multiboot specification
Closes: 500336 501306
Changes: 
 grub (0.97-47lenny1) unstable; urgency=high
 .
   * update-grub: Try to regenerate device.map when grub-probe fails (and
     inform the user about it).  Thanks Raphaël Hertzog.  (Closes: #501306)
   * update-grub: Do not attempt to detect CONFIG_PARAVIRT Xen images.
     Thanks Raphaël Hertzog et al.  (Closes: #500336)
Checksums-Sha1: 
 94e7b82c7300e9c76c9fc9428b6728b5441ff517 1335 grub_0.97-47lenny1.dsc
 7d19066491f09c483efa06b07e55a57b06fecfa6 93826 grub_0.97-47lenny1.diff.gz
 88c2cd84ce3b90f8dd1f1ba75a5553cb89510822 924212 grub_0.97-47lenny1_amd64.deb
 59e17ee8b2aeb29f3449b4a56d36eb93b78dfcd6 115486 grub-disk_0.97-47lenny1_all.deb
 dfd030c7284dc2fa718cccd37f9974c6bb8fb740 115502 grub-doc_0.97-47lenny1_all.deb
 15928d7c9ad175f1df90aa575540ae233ef0cf0c 252818 grub-legacy-doc_0.97-47lenny1_all.deb
 88e5d234d245da663cd428ee85cd1478cf20fd29 160550 multiboot-doc_0.97-47lenny1_all.deb
Checksums-Sha256: 
 8e7a302f32c971e188f8df43b685535394ba9eefbd7a6f6eecdfd274ebe0cb9e 1335 grub_0.97-47lenny1.dsc
 af3e003f74ddaed35cbddb70100a1d06ce120340e3ae7316e4e6f20645a08986 93826 grub_0.97-47lenny1.diff.gz
 9cf8199a472b49918221b95990027ec982c33372e2af9971728b3cf1202863f5 924212 grub_0.97-47lenny1_amd64.deb
 063d7606bd0fb985d7bf540ff7430b0ebed9894e311a64913c3f54b7e4ef607c 115486 grub-disk_0.97-47lenny1_all.deb
 98d18cee7efbd5f80f968d04914c904d7c5237ae4a897710996299d7dfaacbac 115502 grub-doc_0.97-47lenny1_all.deb
 1d38ae800107084e25f49dca090db7761712820ddefe1ed14038854bcd5bd0c1 252818 grub-legacy-doc_0.97-47lenny1_all.deb
 b640f7d0bc683079391341eb336d6198219bfc90e369a5ded18e6423fc29e185 160550 multiboot-doc_0.97-47lenny1_all.deb
Files: 
 d57735b6b6742ca407837a4fe5ae57d6 1335 admin optional grub_0.97-47lenny1.dsc
 bac404d0a92757509be9c19085d930a3 93826 admin optional grub_0.97-47lenny1.diff.gz
 4236503893c79c62b09e1f74a89d0116 924212 admin optional grub_0.97-47lenny1_amd64.deb
 44642ddb7cdc680838fd29ad5ffad776 115486 admin optional grub-disk_0.97-47lenny1_all.deb
 7a45eba493eef628cea53df46a3f4136 115502 doc optional grub-doc_0.97-47lenny1_all.deb
 5af0191118eb1c7332933dd25b0132da 252818 doc optional grub-legacy-doc_0.97-47lenny1_all.deb
 0515bea9b1718c8644bb908a262081c8 160550 doc optional multiboot-doc_0.97-47lenny1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkUivMACgkQC19io6rUCv/uDQCbBiFoNoelJ8SlJla++gn3xb5/
gyoAnRK5rEekMMOMEOnhgPE9/A5hr9oN
=b32m
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 22 Jan 2009 07:26:44 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 20:05:39 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.