update-grub ignores pvops kernels on Xen domU

Bug #586756 reported by William Blunn on 2010-05-28
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
grub (Ubuntu)
Undecided
Basavaraj
Nominated for Lucid by snogger

Bug Description

Binary package hint: grub

Ubuntu 10.04 LTS. But the problem also manifests under 9.10 and 9.04.
grub 0.97-29ubuntu60

I am running on a Xen domU.

update-grub seems to have logic in it to choose Xen/non-Xen kernels on Xen-domUs / other systems.

However this logic seems to be flawed.

Nowadays, Xen domUs can use "ordinary" kernels because modern kernels have pvops included.

1. update-grub seems to be looking for kernels with the word "xen" in their name in order to believe that they will work in a Xen domU. This is broken because pvops kernels will work under a Xen domU but will not have the word "xen" in their name

2. update-grub seems to be written on the basis that a kernel will either be "Xen" or "non-Xen" and those are mutually exclusive. This is broken because "ordinary" kernels with pvops will be suitable for both Xen and non-Xen working.

The upshot is that for me update-grub ignores a perfectly usable "ordinary" kernel, which I would rather it recogised and configured for me.

My quick workaround was to fudge update-grub to treat all kernels as Xen kernels. This made update-grub recognise the kernel, configure it into /boot/grub/menu.lst, and the system was then able to boot correctly.

As that kernel does in fact work fine, but update-grub ignored it, this suggests a shortcoming in the behaviour of update-grub.

The fix I would suggest would have two parts:

1. Improve the ability of update-grub to recognise Xen-capable kernels. This could be done by adding another possibility 'or'-ed with existing detections, on the detection of Xen-capable kernels. (Though see the second part because if the paradigm is altered it may mean a re-write to that part of the program.)

Take the name of the kernel image, e.g. vmlinuz-2.6.32-3-amd64, then take off the "vmlinuz-" from the beginning to leave "2.6.32-3-amd64". Store this in a variable "kernelSuffix". Then look for the existence of a file "/lib/modules/${kernelSuffix}/kernel/drivers/block/xen-blkfront.ko". If this file exists, then you have a kernel which is suitable for Xen-domU operation (and probably ALSO non-Xen-domU operation).

2. Considering the Xen/Non-Xen attribute ("is_xen") this either needs to have a third option "Either", OR it could be split into two attributes "xenDomU" (yes/no or "1"/"") and "nonXenDomU" (yes/no or "1"/""). Kernels which are detected as Xen domU suitable by the detection of the xen-blkfront.ko kernel module will likely be suitable for BOTH Xen-domU operation AND non-Xen-DomU operation, so should be considered in both cases of Xen-domU and non-Xen-domU systems.

William Blunn (bill+launchpad) wrote :

Perhaps I will produce a patch...

William Blunn (bill+launchpad) wrote :

This patch is intended to make update-grub:

(a) be better at detecting kernels which are suitable for user in a Xen domU, and

(b) be able to treat some kernels as suitable for both Xen-domU operation AND non-Xen-domU operation (previously it was one or the other but not both)

tags: added: patch
William Blunn (bill+launchpad) wrote :

Update:

Previously I was running over the 2.6.32 kernel out of Debian Squeeze, and saw the behaviour mentioned previously.

I have now switched to the 2.6.32 kernel implied by the Ubuntu package "linux-image-2.6.32-22-virtual" (version 2.6.32-22.33), which is 2.6.32-22-server.

If I now run the original unpatched "update-grub", it finds all the relevant kernels I have installed, and does not ignore any of them, i.e. the behaviour as reported previously no longer happens.

However I *am* running inside a Xen domU. In theory, if the bug I reported were true, "update-grub" should be ignoring all of my kernels.

So what is going on?

The answer is that "update-grub" does NOT believe it is running inside a Xen domU, when in fact it is running inside a Xen domU, which appears to be another bug.

The two bugs together mean that update-grub does not ignore relevant kernels inside a domU. However it is not ignoring them for the wrong reasons. (I suppose you could call it a white box bug.)

There is a bit starting around line 1406:

   1406 if [ "$indomU" = "detect" ]; then
   1407 if [ -e /proc/xen/capabilities ] && ! grep -q "control_d" /proc/xen/capabilities; then
   1408 indomU="true"
   1409 else
   1410 indomU="false"
   1411 fi
   1412 fi

On my system (which is running inside a Xen domU), when running the Ubuntu kernel, the directory /proc/xen is empty. As such, the second "if" test finds nothing and sets "indomU" to "false".

(Under the Debian kernel, this must have been resolving to "true". Though switching back to the Debian kernel again, I am seeing false. Queer.)

So the "indomU" indicator is being computed incorrectly as "false" when actually running inside a domU.

I would speculate that the means of detecting whether inside a domU was based on earlier kernel behaviour and no longer works correctly.

So I would say we may need to use a second way of checking if we are inside a domU.

Sniffing around, we may be able do this by reading /sys/hypervisor/type. On my system that results in the string "xen".

So perhaps we could say something like:

if ( [ -e /proc/xen/capabilities ] && ! grep -q "control_d" /proc/xen/capabilities ) \
  || [ "`cat /sys/hypervisor/type 2>/dev/null`" = xen ] ; then
    indomU="true"
else
    indomU="false"
fi

This should then give us a better idea of whether we are inside a Xen domU.

ward (ward-pong) wrote :

I'm using the 'ec2' kernels that come with lucid, which show the same problem. They have CONFIG_XEN_UNPRIVILEGED_GUEST set, and the update-grub script only checks for CONFIG_XEN_PRIVILEGED_GUEST.

There is a second (small) bug on line 1416 by the way:

 if `echo "$xenKernels" | grep -q "$kern "` || `echo "$kern" | grep -q "xen"`; then

That space after $kern in the first grep -q command causes the last kernel to always be dropped off the list, which is not desirable. It even means that if there's only one Xen kernel found, it will never be added to menu.lst.

Sébastien Bernard (sbernard) wrote :

One user using grub and natty is bitten by this problem.
All kernels since the 2.6.37-9 have the XEN_PRIVILEGED_GUEST set.
update-grub uses this criteria to check if the kernel is a Xen kernel or a normal kernel.

That means that normal kernels don't show up in the grub menu since the 2.6.37-9 kernel.

This is especially nasty for the natty and for the maverick version.

Sebastian Lemke (s-lemke) wrote :

Hi !

have excatly the same problem with the -server and generic-pae kernel. In my configs XEN_PRIVILEGED_GUEST is NOT set (acutal system, yesterday updated).

I have done a small fix for update-grub:

--- update-grub.old 2011-04-06 17:37:34.198906717 +0200
+++ update-grub 2011-04-06 17:37:20.437907250 +0200
@@ -1382,7 +1382,7 @@

 xenKernels=""
-for ver in `grep -l CONFIG_XEN_PRIVILEGED_GUEST=y /boot/config* | sed -e s%/boot/config-%%`; do
+for ver in `grep -l CONFIG_XEN=y /boot/config* | sed -e s%/boot/config-%%`; do
   # ver is a kernel version
   kern="/boot/vmlinuz-$ver"
   if [ -r $kern ] ; then
@@ -1413,7 +1413,7 @@

 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
- if `echo "$xenKernels" | grep -q "$kern "` || `echo "$kern" | grep -q "xen"`; then
+ if `echo "$xenKernels" | grep -q "$kern"` || `echo "$kern" | grep -q "xen"`; then
                is_xen=1
        else
                is_xen=

Regards,
Sebastian

William Blunn (bill+launchpad) wrote :

Without wishing to sound like a voice from the peanut gallery:

* Bug was reported 10 months ago

* Bug was reported clearly, and at length, using proper (English) language, properly spelled and punctuated

* Problem was analysed and a potential solution devised and provided

* Subsequently, further problems have been identified, and potential solutions devised and provided for those also

It seems to me that "the community" has very much "done its bit" on this bug, resulting in good quality information in the comments.

It seems to me that it should not be difficult for the mainter to process this bug, and improve the package.

However I cannot see any comments on here to say that any significant actions (such as assessing the suggested changes and applying them) have been taken.

I would be grateful if this bug could get some air time with the maintainer.

William Blunn (bill+launchpad) wrote :

Errata for previous comment:

"... should not be difficult for the mainter to process ..."

should have been

"... should not be difficult for the maintainer to process ..."

Colin Watson (cjwatson) wrote :

Sorry for missing this earlier - I pay rather more attention to grub2 than grub these days. I think this is already fixed in Ubuntu 11.04, though; see bug 692691. Perhaps you could check that and confirm that it matches your bug? The patch I applied is here:

  http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/revision/904

I hadn't realised that this also affected older releases. It should be possible to backport it, if so.

Sebastian Lemke (s-lemke) wrote :

Hi !

Patch looks good to me - on my system it works fine.

It would be good if the patch could be applied quickly - my system is lucid (LTS).

Thanks,
Sebastian

ward (ward-pong) wrote :

Yes, *please* backport this fix.

Sebastian Lemke (s-lemke) wrote :

Hello,

i got an update for update-grub - the Xen Kernels are now recognized correct - except the first one.
The typo mistake has not been fixed:

--- update-grub.original 2011-06-07 14:55:56.849136053 +0200
+++ update-grub 2011-06-07 14:56:09.773353733 +0200
@@ -1413,7 +1413,7 @@

 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
- if `echo "$xenKernels" | grep -q "$kern "` || `echo "$kern" | grep -q "xen"`; then
+ if `echo "$xenKernels" | grep -q "$kern"` || `echo "$kern" | grep -q "xen"`; then
                is_xen=1
        else
                is_xen=

Please fix this also,
Thanks,
Sebastian

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in grub (Ubuntu):
status: New → Confirmed
dino99 (9d9) wrote :

This is no more a supported version; and grub legacy upstream is also stopped, only receiving possible random fixes locally

Changed in grub (Ubuntu):
status: Confirmed → Invalid

update-grub.old 2011-04-06 17:37:34.198906717 +0200
+++ update-grub 2011-04-06 17:37:20.437907250 +0200
@@ -1382,7 +1382,7 @@

 xenKernels=""
-for ver in `grep -l CONFIG_XEN_PRIVILEGED_GUEST=y /boot/config* | sed -e s%/boot/config-%%`; do
+for ver in `grep -l CONFIG_XEN=y /boot/config* | sed -e s%/boot/config-%%`; do
   # ver is a kernel version
   kern="/boot/vmlinuz-$ver"
   if [ -r $kern ] ; then
@@ -1413,7 +1413,7 @@

 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
- if `echo "$xenKernels" | grep -q "$kern "` || `echo "$kern" | grep -q "xen"`; then
+ if `echo "$xenKernels" | grep -q "$kern"` || `echo "$kern" | grep -q "xen"`; then
                is_xen=1
        else
                is_xen=

Changed in grub (Ubuntu):
assignee: nobody → Group_6 (basavarajmulagund92)

update-grub.old

 xenKernels=""
-for ver in `grep -l CONFIG_XEN_PRIVILEGED_GUEST=y /boot/config* | sed -e s%/boot/config-%%`; do
+for ver in `grep -l CONFIG_XEN=y /boot/config* | sed -e s%/boot/config-%%`; do
   # ver is a kernel version
   kern="/boot/vmlinuz-$ver"
   if [ -r $kern ] ; then
@@ -1413,7 +1413,7 @@

 sortedKernels=""
 for kern in $(/bin/ls -1vr /boot | grep -v "dpkg-*" | grep "^vmlinuz-") ; do
- if `echo "$xenKernels" | grep -q "$kern "` || `echo "$kern" | grep -q "xen"`; then
+ if `echo "$xenKernels" | grep -q "$kern"` || `echo "$kern" | grep -q "xen"`; then
                is_xen=1
        else
                is_xen=

  • bug.docx Edit (16.1 KiB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
Changed in grub (Ubuntu):
status: Invalid → Fix Committed
status: Fix Committed → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments