grub / grub2 conflicts

Peter Jones pjones at
Thu Sep 15 14:53:56 UTC 2011

On 09/15/2011 10:36 AM, Richard W.M. Jones wrote:
> On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
>> On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
>>> So I propose that we drop this conflicts and fix grubby instead.
>> No. It is not sane to have multiple bootloaders installed on one
>> machine.
> There's an interesting verbal trick there.  "multiple bootloaders" are
> not installed.  Multiple versions of the grub RPM package are
> installed.  Only one bootloader would be installed on the host.

It's really not useful or reasonable to think of grub and grub2 as "multiple
versions of the same bootloader" - they don't share tools, for example. But
even so, multiple versions of the same bootloader doesn't make sense either.

>> Requiring the ability to do so adds a significant amount of
>> extra complexity to the tools associated with it for no useful benefit.
> The useful benefit was outlined in the original email.

It really wasn't - it's still unclear why anybody would choose to do things
that way. On the face it's a completely wrong choice.

>> Just install the grub package in the guest, and chroot into the guest if
>> you need to run grub-install there.
> Running tools from out of the guest is insecure.  There are several
> ways in which a guest could exploit the host if we did this.  See
> "Security" here for some issues:

"I wrote a web page about my opinions" does not make them fact. But even if we
took as given that it's somehow better not to use packages in the guest, it's
still not a reason to have the packages *unpacked and installed* on the host
system. Doing this introduces many more chances for exploitation and plain old
corruption and errors. At the very least it should be using raw, non-installed
packages on the host rather than installed ones. Which, by the way, Fedora
already has tools to accomplish.


Power corrupts.  Absolute power is kind of neat.
		-- John Lehman, Secretary of the Navy, 1981-1987

More information about the devel mailing list