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