On Sat, Jul 4, 2020 at 10:19 AM Lennart Poettering <mzerq...@0pointer.de> wrote:
> If it way my decision I'd propose the following as the path to the > future: > > 1. Unify/standardize on the boot loader spec, not the boot loader > > 2. Let's use UEFI as model and make MBR boots more alike UEFI then the > other way round (right now, UEFI boots in grub are considered a > special case, and booting on UEFI is attempted to be as close as > possible to MBR). i.e this is a race-to-the-bottom > vs. race-to-the-top issue: make the stuff that doesn't work like > today's industry standard work like it, and don't make today's hw > work like the industry standard of yesteryear. > > Specifically this means: > > a. Teach grub proper boot loader spec support (and maybe boot loader > interface support too, > i.e. https://systemd.io/BOOT_LOADER_SPECIFICATION + > https://systemd.io/BOOT_LOADER_INTERFACE) > > b. Prepare a static no-module build of Grub that reimplements roughly > how booting on EFI works: i.e. support only VFAT file systems, then > search for suitable partitions (ESP/XBOOTLDR), and retrieve boot > loader spec entries from them, and populate the menu by it, and > that's it. Do this the same way on all archs we support, regardless > if MBR or ARM or EFI boot protocols. > > As I understand a good chunk of a/b already exists. I agree with all of this. But multiple projects (distros but also project within even Fedora) boot differently and put pressure on bootloader folks. GRUB is simultaneously unwieldy and indispensable. The cost of abandoning it, or reorganizing either the upstream approach or Fedora's approach to it, is incredible to imagine let alone implement. And thus far upstream GRUB seems intractable on Bootloaderspec, or giving sufficient feedback on modifications to make it viable. It's a sand trap. Why do the security folks want POSIX and SELinux labels on the contents of /boot? I've never really gotten a straight answer on this, but I know it's considered important and a sticking point for why some folks do not want the kernel and initramfs and bootloader configuration files on FAT. And can it be mitigated some other way? Maybe not persistently mounting /boot and /boot/efi or mounting them on-demand elsewhere only when they need to be modified? There are other use cases folks are interested in. Here's one: https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs That aims to make it possible to support a snapshot/rollback regime. There needs to be a way to pair the states of /boot and / so that the kernel we're using to boot a rollback, has modules available on the rolledback /usr. That does not need to be done with Btrfs, even though it's probably easier, since we have examples of this already from (open)SUSE that we know work very reliably. It's a solved problem that is also well understood. The unsolved component to that though is how to do it with Bootloaderspec. Is it possible at the same time we figure out a way to not require /boot to be Btrfs? I'm open to the idea even though I'm not sure what it looks like. Hence why this is an option in the proposal, not part of the base proposal. Everyone wants out of the sand trap, but we're also more comfortable sticking with the problems we know rather than jumping into problems we don't know. And then also RH/Fedora bootloader folks are busy enough as it is holding up the fort, with few cycles to look at planning and implementing a new design. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
