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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
