Message-Id: <B6CCAB6A-D340-47F8-9231-1280151552DC@colorremedies.com>
Date:	Sat, 9 Feb 2013 17:17:58 -0700
From:	Chris Murphy <lists@...orremedies.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: GRUB and the risk of block list corruption in extX


On 2013-02-07 15:50:07 GMT Eric Sandeen wrote:

> To be clear, this is only the case when installing the bootloader itself to a partition containing a filesystem, not when installing to the MBR, correct?

Correct.

> Which is different than saying "/boot is on ext4" - it's putting the bootloader itself on a partition containing a filesystem, something which is a bit more unusual, I think.

Some users apparently want distribution specific boot loaders as secondary, chain loaded from a primary boot loader that goes in the MBR gap.



On 2013-02-07 20:53:35 GMT Theodore Ts'o wrote:

> This only happens if grub2 can't install itself in the space between the MBR and the beginning of the first partition.

The message also happens when the user explicitly requests grub-install to "install to a partition" instead of to the MBR gap, on ext.

grub-install /dev/sda1

instead of

grub-install /dev/sda

There are different behaviors depending on file system: Not allowed at all on XFS (with or without --force); only possible with --force on ext; only possible without --force on btrfs.


> I think the grub2 developers are being far too paranoid.


Possibly. On the one hand syslinux/extlinus works in a similar way to GRUB's --force option creating a blocklist, although I'm not familiar enough with extlinux to know if there's a significant difference.

On the other hand…

> There are some folks who are proposing that we use a bootloader inode:
> for grub's benefit. 

Who are requesting this? If not GRUB's devs, it would seem there are other developers who are also paranoid.

> But it's not something that has been terribly high priority, since it's basically more of a security blanket for the grub2 developers more than anything else….

It may be a security blanket for grub2 developers. However, it appears to me users want a security blanket also. 

Users can do what they want now, with existing tools. The bug report details the two simple commands to enable this, but some users find that inadequate. What they really want is a GUI switch in their OS installer to do this for them, and would be managed by fulfilling RH BZ 886502 (related bug to the OP's cited bug).

Despite my bias against two bootloaders (I think it's ridiculous, but then I prefer 1/2 a boot loader), the question I have is if a blocklist is really needed to find and load the 2nd boot loader? Because needing a blocklist in the VBR implies the first boot loader doesn't understand ext(4). If true, before engineering file system changes, users need to upgrade their ancient primary boot loader.

GRUB legacy 5+ years ago (and extlinux) can "chain" load to GRUB 2 by directly reading ext, and locate /boot/grub2/i386-pc/core.img; even if it is fragmented, even if aggressive fsck, or online defragmenting is performed. The only thing the blocklist does is point to core.img, the thing that's normally in the MBR gap (or BIOS Boot partition on GPT).

And GRUB2 as a primary bootloader goes a step easier which is it can find, load, display and execute distribution specific grub configuration files, both current and legacy formats. It's not even necessary to chain load from GRUB2 to GRUB1 or 2.

So I don't actually understand what the request really is for, it seems there are multiple other ways of arriving at the goal, and the request for blocklist safety and boot loader inodes is uncompelling. 

Maybe increasing ext's VBR is useful since GRUB and extlinux already have code to leverage that method of embedding for btrfs, which has a 64KB pad at the start (vs ext's 1KB). But even here I'm skeptical of the need.


Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists