Bug#500336: patch for grub detection

[Raphael Hertzog]

Hi,

we need to decide on a fix for this RC bug and get a new grub uploaded.
So lets restart the discussion.

On Tue, 21 Oct 2008, Ian Campbell wrote:
> On Mon, 2008-10-20 at 21:18 +0200, Thomas Viehmann wrote:
> > 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.
> 
> Both what?

Both booting in dom0 and in domU AFAIK.

> > So the problem would bite people upgrading grub but not the kernel.
> 
> Someone who installs 2.6.26-1-xen-amd64 in a Lenny domU with the Lenny
> version of grub would end up with a menu.lst which did not contain this
> kernel, which would be incorrect.

But this is only a problem for pygrub users and it looks like pygrub is
not even packaged for Debian. 

Does this fix constitute a regression compared to etch ?
Does this fix constitute a regression compared to what's in lenny now ?

> > 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.
> 
> I think in an earlier version of the patch which became the current
> stuff had a magic variable thing. I think I'd be happy with a
> commented-out-magic IFF there is absolutely no way to make it work by
> default.

Are you referring to something like what has been suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479478 ?

In any case, Ian, we need to go forward and if the patch proposed by
Thomas doesn't satisfy you, can you prepare an alternative patch
that would address your concerns ?

I wonder if we have a reliable way to know that the target system
is a domU when we install it with d-i. After all, from what I understand
that's the main problem to solve to be able to special-case the kernels
that can boot in a domU only.

And I agree with Thomas that including a non-bootable kernel in menu.lst
is bad. That's why this bug is RC… so if we have to choose beetwen missing
some domU kernels in domU and having unbootable kernels in other
situation, we should choose the former.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/