The Fedora Project has changed its collective mind, and Fedora 37 won’t require UEFI – it will still install and run on BIOS-only systems.
Last month we reported on some simplifications planned for Fedora 36 and 37. Aside from the changes to console graphics support, there was a proposal to require UEFI firmware, as a step towards removing support for booting using the old-style legacy BIOS boot process.
Apparently, this generated more discussion than several previous wildly contentious changes, including, in the words of project lead Matthew Miller, “
systemd-resolved, btrfs-by-default, and even switching the default editor to
Why does it matter?
The UEFI/BIOS changeover remains important for a variety of reasons, and it’s not as simple as wanting to run a modern Linux on old PCs.
Fedora is a relatively cutting-edge distro which prides itself on incorporating the latest Linux technology, and that also means proactively removing support for older technologies.
Contrast this with, for instance, Debian – which is generally very technologically conservative – or Ubuntu, which has a cycle of long-term supported releases and more experimental short-lived ones.
Inside the greater Red Hat ecosystem, those wanting stability and reliability over long periods would generally gravitate towards Red Hat Enterprise Linux (or third-party rebuilds such as Alma and Rocky Linux). Those wanting something in between might look to the relatively new CentOS Stream.
From this, one might reasonably conclude that potential Fedora users are unlikely to install it on hardware so old that it doesn’t have UEFI. Thus, it should be acceptable to require UEFI. However, it’s not as simple as that: it’s not all about hardware any more. The majority of Linux instances run inside virtual machines on top of various hypervisors.
Hypervisors essentially work by emulating a whole PC, meaning that an OS inside a VM “sees” an emulated PC, not the real host system. That includes an emulated motherboard with its own firmware, and for most present-day hypervisors, the default firmware is a legacy BIOS. For open source hypervisors, that’s often the open-source SeaBIOS.
For instance, in VirtualBox 6.1 (released December 10 2019 and still current), the default for new VMs is a BIOS-only system, with just an optional tickbox under *Settings: System: Motherboard”* which reads “Enable EFI (special OSes only).” (We suspect that “special OSes” really means macOS.)
Even on bare metal, it’s not a simple yes/no choice. As mentioned before, The Reg FOSS desk is quite keen on old Thinkpads with seven-row keyboards. These came with UEFI firmware that emulates a legacy BIOS, and which you get depends on a setting in the firmware. If you choose a traditional BIOS boot only, the machines act like traditional PCs, complete with a “press F1 for setup” message on the POST screen.
If you choose UEFI boot only, they look just like a later model PC, after which in Windows 10 to get into the firmware settings requires a special troubleshooting option.
Or, you can set them to try booting both methods. In that case, the question becomes in which order: UEFI first, followed by BIOS boot, or BIOS first, then UEFI boot? If you pick either of those, then the laptop behaves either as a UEFI box or a BIOS one depending on which medium it booted from. If that’s a removable medium such as a Ventoy USB key, it can boot in both modes.
This situation is by no means confined to Lenovo machines: the author has encountered it on high-end Dell kit as well. As an example, one PC had three UEFI-aware OSes installed.
Your fearless researcher booted from a Ventoy key – which tries BIOS boot first – and updated one of the installed OSes. The result was bricking the machine, needing a full hard disk reformat and the reinstallation of all three OSes. Literally hours of “fun”. This wasn’t the last time, either.
Summary: it’s complicated. It will be years until the ghost of legacy BIOS boot is entirely exorcised – not only from Fedora.
Thanks to commenter Adam Williamson for pointing out that this was just a proposed change, rather than one that had been accepted and was certain to happen.