> On Apr 5, 2022, at 8:08 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton@xxxxxxxxxx> 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 entire >> >> == Owner == >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří >> Konečný]], [[User:bcl| Brian C. Lane]] >> * Email: rharwood@xxxxxxxxxx >> >> >> == 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 > > 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. > > 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. > For similar reasons, I agree with Neal. There are a number of Amazon EC2 instance types that would be left out of the next generation. I think it would be better to identify the usage in some way and create a general awareness that it is being removed prior to outright removing it. The deprecation period is important IMO. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
