update-grub ignores pvops kernels on Xen domU
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub (Ubuntu) |
Confirmed
|
Undecided
|
Basavaraj | ||
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/
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. 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.
tags: | added: patch |
Perhaps I will produce a patch...