On Do, 02.07.20 15:30, Brandon Nielsen (nielsenb(a)jetfuse.net) 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