Bug#500336: patch for grub detection

[Ian Campbell]

On Wed, 2008-10-29 at 17:56 +0100, Raphael Hertzog wrote:
> 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.

OK, yes this is true. I thought maybe he meant native vs on Xen which
isn't (using "both" in a situation with three option is a little
confusing ;-)) or maybe something else since the quoted paragraph
doesn't mention dom0 at all...

> > > 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. 

It's just part of Xen:

$ dpkg -S /usr/lib/xen-3.2-1/bin/pygrub 
xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub

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

I think in both cases it depends on whether you are in the "I've got a
kernel entry I can't boot" camp or the "I've not got a kernel entry I
could boot" camp.

> > > 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 ?

Yes something like that.

I previously had concerns because /proc/xen doesn't exist on pv ops
kernels, but since we would not go down this path on a pv ops kernel
this doesn't even make sense to me anymore, I'm not sure what I was
thinking... Perhaps I was considering the future existence of pvops
domain 0 kernels but since they don't yet exist and probably will
have /proc/xen lets not worry.

> 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.

Under 32 bit d-i will install a 686-bigmem kernel (i.e. a paravirt ops
one) and the current and patched update-grub would do the right thing
since CONFIG_XEN+CONFIG_PARAVIRT => update-grub will always make a
native style entry.

If a user manually installs the non-paravirt -xen-686 kernel in a domU
(which is not unlikely, even if I think its unnecessary...):
      * currently it will work, since there is no special casing =>
        create a native style entry.
      * with the proposed patch it will break. Since CONFIG_XEN + NO
        CONFIG_PARAVIRT => No grub entry.
      * with something like 479478 incorporated into the CONFIG_XEN + NO
        CONFIG_PARAVIRT case then it should work since domU=1 => Create
        a grub entry.

Since there has historically been no d-i support for Xen (and still
isn't for 64 bit) some users will be using constructing a domU using
tools such as xen-tools or debootstrap (I'm sure there are others). In
that case I'd expect them to get the -xen-686 image since the paravirt
ops stuff hasn't propagated to all those tools yet.

Similarly people upgrading a domU from Etch would get a -xen-686 image
since that is what they have now.

> 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.

I'm not so sure I agree (there are plenty of ways to end up with invalid
grub configurations surely, installing pae on a non-pae machine for
example) but I think given the above we have a solution which works for
both cases anyway, so lets ignore that little disagreement...

Ian.
-- 
Ian Campbell
Current Noise: The Meads Of Asphodel - 80 Grains Of Sand

Save the bales!