Bug#500336: patch for grub detection

[Thomas Viehmann]

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/