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? > 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. > 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. > 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). If you are the admin of a domU with no access rights to dom0 (common with hosting providers) then I think the two are equivalent. Ian. -- Ian Campbell Some men are discovered; others are found out.
signature.asc
Description: This is a digitally signed message part
