On Feb 19, 2013, at 1:47 AM, Martin Wilck
>> Effectively you're asking for indefinitely supporting GRUB 0.9, by
requiring other dependencies so that can happen.
> The only other dependency I am asking for is the ability for the distro
> boot loader to be installed in the root or boot partition. That's not
You're asking for more than you apparently realize. You said you wanted to
be able to support KlingonFS, but your idea can't do this alone. I already
used XFS as a real example file system that will not be bootable using your
idea, and I see it as conclusive proof of a fundamentally broken concept.
If you want new file systems to support booting, then the primary boot
loader needs to be able to understand that file system.
Next, your idea requires the installer UI code to check the target file
system before installing the boot loader. Every file system has a different
location for this blocklist or boot loader code, there is no
standardization. And in the case of XFS, this test fails and now you need
extra UI code to indicate to the user that installing to an XFS partition
isn't supported. And you need code that warns the user that even though a
boot loader is being installed, that the installed system won't be bootable
out of the box because the 1st boot loader doesn't know about the 2nd.
And all of this needs to be tested.
Instantly you're talking about *dozens* of people, dozens of hours of
coding and testing. And this is because you don't want to type
grub2-install --force. I don't understand how you think a GUI installer
enabled to install in root/boot is "not much" and yet for you to type
--force is too much?
> The biggest argument for Fedora not being able to do this has been the
> claimed danger of block list corruption.
The biggest argument is:
> That's the only aspect of this discussion that is worth bothering the
> GRUB developers with. The validity of my use case should be discussed