Re: The future of legacy BIOS support in Fedora.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux