On Saturday, July 4, 2020 9:19:34 AM MST Lennart Poettering 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. GRUB2 + BIOS boot is currently the best way to boot a system, as it actually supports situations such as full disk encryption, boot from btrfs or ZFS, including ZFS with native encryption. > 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) That systemd throws some crap out doesn't make it a standard. There's no reason for GRUB to adopt this, or for anyone else to use this. > 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. There is even less reason to *remove* features from GRUB, to make up for the alternative bootloaders having less. > As I understand a good chunk of a/b already exists. > > With these changes it doesn't matter too much which boot loader is > used, it can be sd-boot or Grub. Or it could even be the native boot > loader spec support in firmware (i.e. LinuxBoot). It doesn't matter > anymore. Please note that projects such as Libreboot (blobless coreboot with GRUB as the payload) currently assume that the installed system either uses GRUB2 or syslinux/isolinux. > but the effect of this approach would be great: suddenly "systemctl > kexec" and "systemctl reboot --boot-loader-entry=" would jus twork for > all these boot loaders, and installers could all understand each > other's drop-ins and logic, on all archs... And you could switch boot > loaders any day and there's a major chance things would just work. You > could multi-boot between Linux distros without having the boot loaders > overwrite each others data all the time. How does `systemctl kexec` differ from `kexec`? Can it not simply use `kexec` under the hood? What's the benefit of supporting `--boot-loader-entry=`? You can already multiboot between Linux distros, and we've been able to do so, as well as between other families of OS, for about two decades now. > Note that I personally would actually prefer if the firmware would > natively implement the boot loader spec and we wouldn't have to have > sd-boot around at all. Such a scheme would be fantastic actually, as > it would remove so many variables from the stack. > > sd-boot exists only to add the minimum on top of EFI to make the above > work, i.e. something that in an ideal world would just be subsumed by > the firmware itself. We don't need more bloat in the UEFI stack. It's already painfully specific to Windows based platforms, and it's a complete hack that it works for our systems now. Do you remember the state of UEFI in the RHEL6 days? -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
