On Tue, Apr 5, 2022, 11:15 Neal Gompa <ngomp...@gmail.com> wrote: > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcot...@redhat.com> wrote: > > > > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > > > == Summary == > > Make UEFI a hardware requirement for new Fedora installations on > > platforms that support it (x86_64). Legacy BIOS support is not > > removed, but new non-UEFI installation is not supported on those > > platforms. This is a first step toward eventually removing legacy > > BIOS support entirely. > > > > == Owner == > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > > Konečný]], [[User:bcl| Brian C. Lane]] > > * Email: rharw...@redhat.com > > > > > > == Detailed Description == > > UEFI is defined by a versioned standard that can be tested and > > certified against. By contrast, every legacy BIOS is unique. Legacy > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > > and on its way out. As it ages, maintainability has decreased, and > > the status quo of maintaining both stacks in perpetuity is not viable > > for those currently doing that work. > > > > It is inevitable that legacy BIOS will be removed in a future release. > > To ease this transition as best we can, there will be a period (of at > > least one Fedora release) where it will be possible to boot using the > > legacy BIOS codepaths, but new installations will not be possible. > > While it would be easier for us to cut support off today, our hope is > > that this compromise position will make for a smoother transition. > > Additional support with issues during the transition would be > > appreciated. > > > > While this will eventually reduce workload for boot/installation > > components (grub2 reduces surface area, syslinux goes away entirely, > > anaconda reduces surface area), the reduction in support burden > > extends much further into the stack - for instance, VESA support can > > be removed from the distro. > > > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > > mandates that machines must have been made after 2006). Like the > > already accepted Fedora 37 change to retire ARMv7 support, the > > hardware targeted tends to be rather underpowered by today’s > > standards, and the world has moved on from it. Intel stopped shipping > > the last vestiges of BIOS support in 2020 (as have other vendors, and > > Apple and Microsoft), so this is clearly the way things are heading - > > and therefore aligns with Fedora’s “First” objective. > > > > == Feedback == > > Dropping legacy BIOS was previously discussed (but not proposed) in 2020: > > > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > Important, relevant points from that thread (yes, I reread the entire > > thread) that have informed this change: > > > > * Some machines are BIOS-only. This change does not prevent their use > > yet, but they are effectively deprecated. grub2 (our default > > bootloader) is already capable of both BIOS and UEFI booting. > > * Drawing a clear year cutoff, let alone a detailed list of hardware > > this change affects, is basically impossible. This is unfortunate but > > unlikely to ever change. > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > * There is no way to deprecate hardware without causing some amount of > friction. > > * While at the time AWS did not support UEFI booting, that is no > > longer the case and they support UEFI today. > > > > == Benefit to Fedora == > > UEFI is required for many desirable features, including applying > > firmware updates (fwupd) and supporting SecureBoot. As a standalone > > change, it reduces support burden on everything involved in installing > > Fedora, since there becomes only one way to do it per platform. > > Finally, it simplifies our install/live media, since it too only has > > to boot one way per arch. Freedom Friends Features First - this is > > that last one. > > > > == Scope == > > * Proposal owners: > > ** bootloaders: No change (existing Legacy BIOS installations still > supported). > > ** anaconda: No change (there could be only optional cleanups in the > > code). However, it needs to be verified. > > ** Lorax: Code has already been written: > > https://github.com/weldr/lorax/pull/1205 > > > > This pull request primarily drops legacy BIOS support by dropping > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > support there if we reuse GRUB there too. Other distributions > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on > live media. > > > * Other developers: > > ** libvirt: UEFI works today, but is not the default. UEFI-only > > installation is needed for Windows 11, and per conversations, libvirt > > is prepared for this change. > > ** Virtualbox: UEFI Fedora installs are working and per virtualbox > > team, UEFI will be/is the default in 7.0+. > > ** The Hardware Overview page should be updated to mention the UEFI > > requirement: > https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/ > > > > * Release engineering: [https://pagure.io/releng/issue/10738 #Releng > > issue 10738] > > > > * Policies and guidelines: N/A (not needed for this Change) > > > > * Trademark approval: N/A (not needed for this Change) > > > > * Alignment with Objectives: N/A > > > > == Upgrade/compatibility impact == > > Systems currently using Legacy BIOS for booting on x86_64 will > > continue to do so. > > > > However, this modifies the baseline Fedora requirements and some > > hardware will no longer be supported for new installations. > > > > == How To Test == > > UEFI installation has been supported for quite a while already, so > > additional testing there should not be required. > > > > == User Experience == > > Installs will continue to work on UEFI, and will not work on Legacy > > BIOS. Our install media is already UEFI-capable. > > > > == Dependencies == > > None > > > > == Contingency Plan == > > Leave things as they are. Code continues to rot. Community > > assistance is required to continue the status quo. Current owners > > plan to orphan some packages regardless of whether the proposal is > > accepted. > > > > Another fallback option could be, if a Legacy BIOS SIG organizes, to > > donate the relevant packages there and provide some initial mentoring. > > Longer term, packages that cannot be wholly donated could be split, > > though it is unclear whether the synchronization thereby required > > would reduce the work for anyone. > > > > * Contingency mechanism: Delay until next release. > > * Contingency deadline: Beta freeze > > * Blocks release? No > > > > == Documentation == > > See release notes. > > > > == Release Notes == > > Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in > > favor of UEFI. While systems already using Legacy BIOS to boot are > > still supported, new legacy BIOS installations on these architectures > > are no longer possible. Legacy BIOS support will be removed entirely > > in a future Fedora. > > > > (Additionally, the Hardware Overview page should be updated to mention > > the UEFI requirement.) > > > > While I'm sympathetic to this Change, I think this is way too early to > do across the board. UEFI came onto the scene in the PC space in > 2011~2012 with Windows 8, and even to this day, there are sufficiently > buggy hardware platforms that Linux does not boot in UEFI mode: > https://twitter.com/VKCsh/status/1511132132885815307
Those platforms boot Windows with UEFI. If there are outstanding bugs, we're looking at Linux bugs that are being worked around. I even have one such machine, an HP desktop machine that came with > Windows 8. My current desktop PC has problems booting Linux UEFI as > well, though I've done "clever" things to work around that. I don't > expect most users to be able to deal with that. Server platforms were > *worse* as they were slower to offer UEFI. The first time I was able > to get a server with UEFI was in 2014. > The Dell PowerEdge R710, which was their flagship two socket server launched in 2009, supported UEFI. Even if there were some bugs, I remember it booted in UEFI mode quite fine with several Linux distro back in 2011-2012, because I was at Dell on their server OS team debugging issues that came up with that platform then. And we've still failed to get ARM and RISC-V broadly on board with > UEFI (though that's irrelevant to this Change, even though ARM is > mentioned). > > We also lack solutions for dealing with the NVIDIA driver in > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > Because we still don't have a way to have kernel-only keyrings for > secure boot certificates to avoid importing them into the firmware. Secure Boot is a different matter from UEFI. UEFI provides a lot more than just that feature. Let's not derail this proposal with that. -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
