On Do, 02.07.20 15:30, Brandon Nielsen (nielsenb@xxxxxxxxxxx) wrote: > I don't think removing BIOS support _today_ is the right answer either. I > have BIOS only hardware kicking around, and quite a bit of my UEFI hardware > still supports legacy BIOS booting as well (though I don't use it). > > However, I'm concerned about UEFI feature development / quality assurance > being held hostage by BIOS support for, based on above comments, 5 to 20 > years? Surely as a somewhat leading-edge distribution, we need to start > thinking about some kind of post-BIOS world. > > Perhaps one small step toward that future would be enabling systemd-boot on > new UEFI installs, relegating GRUB2 to BIOS and upgrade installs only? This > split configuration could hang around until support for GRUB2 / BIOS wanes > to the point it can no longer stand under its own weight (much like 32bit > install media). 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. 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. 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. 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. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
