Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification. Dynamic hardware enumeration is performed by every OS anyway, the only hardware that must be initialized is the bootloader/kernel storage.
For the x86 platform, this could be implemented via coreboot (libreboot always reads to me as lib-reboot) with a multiboot payload.
Actually I do not understand which is the problem of Fedora in this case.
The distribution needs to do almost nothing to support either EFI or the legacy BIOS or any other booting method.
That is the job of a bootloader package, not of the Linux distribution. For example I am using syslinux as the bootloader for all my computers, while grub is another example of a frequently used bootloader (but which seems to be excessively complex in comparison with syslinux).
I assume that by supporting only EFI Fedora means that they will remove all bootloaders from their installation image, so that the Linux kernel will be launched by its EFI stub.
I do not know about other bootloaders, but an installed syslinux package occupies only a few megabytes, maybe 10 megabytes at most, so deleting it cannot provide much space for anything else.
I cannot see how deleting a bootloader package may be claimed to be a significant simplification for the maintenance effort of the Fedora distribution.
1. They no longer need to package bios bootloaders
2. They no longer need to support bios booting in the forums - no asking "how do you boot this? Bios, EFI? Have you tried the other?", no telling people "EFI is required for feature X"
3. They no longer need to maintain the bios boot documentation
4. They no longer need to maintain the bios path in the installer/boot media
5. They no longer need to test the bios paths (or hope they don't break and be ashamed if they don't)
6. This makes it easier to switch to a EFI-only default bootloader (instead of Grub 2, which can do both)
Is this massive? No, it's possible to keep maintaining BIOS support. But it's not just freeing space on the package mirrors either.
I agree that restricting the boot method to EFI would reduce the testing time.
Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux.
Restricting the boot method to EFI does not reduce the need for documentation in any way.
The user must still be instructed to enter the BIOS setup and verify whether their computer is not configured to boot in legacy mode, which would prevent booting. Also the user must be instructed to enter the BIOS setup even if the EFI mode is used, because the installation media might not boot anyway, because a wrong boot order is configured for EFI booting, and it must be changed.
The most complex part of the installation is not the booting, but identifying the device where Fedora should be installed, which might be needed to be reformatted and repartitioned.
So a lot of documentation is needed in any case, for novice users.
Removing the booting in legacy mode increases the chances that the installation media will not boot without the user having to modify the BIOS setup, so it increases the chances of the user having to search support in the forums.
>Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux.
~~Yes but syslinux is bios-only. So if you have to support EFI too (and you do because there's EFI-only hardware), you now either need to support syslinux and an EFI bootloader, or a bootloader that supports both like Grub 2.~~
Edit: The article seems to suggest that syslinux can be removed if bios boot is no longer supported. I read that as it being bios-only, but it seems to support EFI?
>Restricting the boot method to EFI does not reduce the need for documentation in any way.
You still need documentation, yes. But you no longer need any documentation for booting with BIOS.
You no longer need to say "X is only supported in EFI, if you boot via BIOS you need to do Y" or anything like that, and keep those parts updated.
The part of the docs that says "To boot EFI, do X. To boot BIOS, do Y" can be cut down to "To boot Fedora, ensure X".
That is a reduction in the amount of documentation.
Yes, it is easy to make a bootable device that can use either syslinux to boot when legacy BIOS is used or efistub to boot when EFI booting is used, eventually loading the same kernel.
> The distribution needs to do almost nothing to support either EFI or the legacy BIOS or any other booting method.
I think you're seriously underestimating the amount of effort the bootloader and hardware enablement teams who work on Fedora put in to making _systems boot Linux at all_.
No, I don't propose that Fedora not support EFI. I do propose that Red Hat use some of its parent company's clout to push hardware vendors in a more open direction.
"Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification"
Not really, none of those ecosystems has a fraction of the device variation that x86 has. When they do (arm) its a giant mess of incompatibility and non working hardware. Modern DT's are basically still tied to the linux kernel the same way that the old arm/platform descriptions tied firmware id's to individual kernel configurations. Which is why the answer to so many arm problems is "match your DT to the kernel revision", god help you if your trying to multiboot a *bsd/etc as well.
PS: Openfirmware is basically dead, that might have been a valid answer in 1998, but even IBM/etc provide alternative boot mechanisms for linux/PPC at this point. The only thing that comes close to a current replacement is UEFI.
Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification. Dynamic hardware enumeration is performed by every OS anyway, the only hardware that must be initialized is the bootloader/kernel storage.
For the x86 platform, this could be implemented via coreboot (libreboot always reads to me as lib-reboot) with a multiboot payload.