On Mon, 2008-10-20 at 08:52 +0200, Robert Millan wrote: > On Fri, Oct 17, 2008 at 11:40:07PM +0200, Thomas Viehmann wrote: > > Hi, > > > > based on Bastian's comments here and a clarification on IRC (thanks!), I > > would like to propose the attached patch. > > I understand that Bastian knows what he's doing, but nevertheless I'd like > this to be okayed by Ian (CCed) before we apply it, since the current > behaviour was stablished by him.
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.
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.
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".
Ian.
>
> Also, I'd like to know if we should adjust GRUB 2 accordingly (its current
> policy is not to special-case Xen images).
>
> Thanks!
>
--
Ian Campbell
No character, however upright, is a match for constantly reiterated attacks,
however false.
-- Alexander Hamilton
signature.asc
Description: This is a digitally signed message part
