[Bug 586756] Re: update-grub ignores pvops kernels on Xen domU

[Launchpad Bug Tracker]

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

** Changed in: grub (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub in Ubuntu.
https://bugs.launchpad.net/bugs/586756

Title:
  update-grub ignores pvops kernels on Xen domU

Status in “grub” package in Ubuntu:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/586756/+subscriptions