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

[Chris Murphy <lists@colorremedies.com>]

On Feb 18, 2013, at 10:16 AM, Martin Wilck <martin.wilck@ts.fujitsu.com> 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