grub / grub2 conflicts
awilliam at redhat.com
Thu Sep 22 19:07:50 UTC 2011
On Thu, 2011-09-22 at 19:47 +0100, Richard W.M. Jones wrote:
> > I hate to say it, but honestly, this thread looks pretty clear-cut to an
> > outsider: pjones and mjg59 are correct, and you and rwmj are incorrect.
> > Their arguments that it is fundamentally unsafe to use the host's grub
> > or, even more so, grub2 in a guest have clear merit, and it honestly
> > feels like the counter-arguments so far have been 'we've got away with
> > it so far' and 'doing it any other way is hard, and we already wrote all
> > this code, so please stop raising inconvenient questions'. Neither of
> > those arguments are at all compelling. I haven't seen a single serious
> > attempt to refute the central point that there is no guarantee of
> > compatibility between any particular two versions or even builds of grub
> > or grub2, and there is not even a mechanism for denoting and testing
> > compatibility. Given this, it's hard to see how it can possibly be the
> > right thing to do to use the host's grub or grub2 in the guest.
> The issue here isn't this at all.
It's become that.
> Issue #1 is that a conflicts was added to grub2, but no reason is
> given. It was apparently done to work around some problem in grubby,
> but again there's no clarity on what the problem(s) were and if there
> would be a better way to fix this.
It seems pretty clear that the thread kinda diverged away from the
actual question of the conflict several days ago, and is now
fundamentally about whether it's correct for libguestfs to expect to be
able to use the host bootloader package to configure the guest's
bootloader. If you are actually accepting that it's incorrect for
libguestfs to do this, but maintaining that the conflict is not valid,
you could do a better job of making that clear, and directing the
argument back to the issue of the conflict.
It's certainly tenable for you to hold that, even if you accept that
your example use case for having both grub and grub2 installed at the
same time (libguestfs) is not a good one for technical reasons, it's
still not necessary or correct for the grub and grub2 packages to
conflict. That's a viable path to go down. But it's not at all clear
from the thread that that's actually what you're doing.
> There is a further issue #2, quite orthogonal, which is that grub
> (upstream) doesn't support offline installation. This is a bug in
> grub 1 & 2 which really should be taken upstream. Nevertheless, it's
> quite possible to use grub1 offline on compatible guests. We don't
> really need to "prove" this, because we do it, and test the results,
> and we publish everything we do in open source code.
Again, your argument is 'we've gotten away with it so far', which was
true of every bad idea ever at *some* point. You can get away with
driving on the wrong side of the street for quite a long time, if you
pick a pretty quiet street; it doesn't make it the right thing to do.
It may be that, if you raised it with the grub team, they would accept
that offline installation using a different version of the code is
something they would like to attempt to support. If so, great, everyone
will be happy. But it doesn't change the fact that, at present, this is
not supported, and libguestfs is doing the wrong thing by relying on it
and hoping to carry on getting away with it.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the devel