Re: GRUB and the risk of block list corruption in extX

[Chris Murphy]

On Feb 18, 2013, at 10:16 AM, Martin Wilck <address@hidden> wrote:

> Using chainloading has the advantage that the primary bootloader (it's
> indeed GRUB 0.9x in my case) doesn't have to understand the more
> advanced filesystems of newer distros.

Updating your boot loader has the advantage that you don't need two boot 
loaders to do what one can do. You haven't explained why GRUB2 can't be your 
primary boot loader.


> It's no problem to boot a btrfs
> distro in this way, and when Fedora 31 comes out with KlingonFS as
> default filesystem, my stupid Grub 0.9X will still be able to chainload
> it, as long as KlingonFS supports embedding a boot loader in its
> partition header.

Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring 
other dependencies so that can happen.

If GRUB 0.91 hadn't added XFS support explicitly, it would be impossible to 
boot from XFS using chainloading because XFS doesn't have a boot sector. 
There's no place to put the blocklist. The way to support booting from new file 
systems isn't to require those file systems have specific features to enable 
chainloading, but to keep the boot loader up to date so it knows how to 
traverse that file system natively.

Chainloading was never a good idea, it was the only idea for supporting 
multiboot on hardware with a brain dead BIOS that was never designed with 
multiboot in mind.

> Fedora 18's GRUB2 will not be able to do that using a
> secondary "grub.cfg", unless someone backports a KlingonFS module for it
> (fortunately, GRUB2 would be able to chainload, too).

This is such a nonsense, red herring argument. There aren't new file systems 
popping up every 6-12 months. And who cares about Fedora 18's GRUB2 in another 
6 years when there is yet another new file system? It should have been upgraded 
or replaced well before then.

Chainloading is a relic of BIOS limitations. It's a relic of boot sectors. 
That's not how things work with UEFI. The way forward is precisely the end to 
chainloading. Not making it easier to do.

> 
> I like the fact that GRUB2 is able to detect foreign installations and
> offer auto-generated boot menu entries for them. But there are some
> scenarios for which the primitive chainloading mechanism is better suited.

Name something you can only do via chainloading that you cannot do by keeping a 
singular primary boot loader up-to-date.

And then state why 'grub2-install --force' on your own is inadequate. Why 
should GUI installers literally encourage users to not upgrade their primary 
boot loader? That objectively seems like a bad idea to me, bad advice. If 
people want to enable a fundamentally flawed workflow like chainloading, 
nothing prevents it. The tools are there, right now, to let you do what you 
want. But to make it easy for the typical user who has no idea what a bad idea 
it is to be using a 6 year old unmaintained, unsupport boot loader, is like 
giving them razor blades and telling them to go play on the free way. It's 
cruel. And it's bad advice.

> 
>> If the enhancement in bug 886502 were to happen, would this enable your 
>> primary boot loader to find either Fedora's grub.cfg, or core.img instead of 
>> depending on a blocklist?
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=886502
> 
> As long as I install F18 on extX, yes. But as explained above, it
> wouldn't be my preferred solution.

I find the explanation uncompelling. If you find GRUB2 overly bloated and 
complicated, then maybe you shouldn't expect your boot loader to boot from new 
file systems; this isn't a required workflow. There's nothing wrong with bootfs 
on FAT32 or ext[234] with syslinux or extlinux, i.e. the kernel and initramfs 
go there, and then placing rootfs on the more advanced file system.


Chris Murphy