On Tue, 2022-04-05 at 09:33 -0700, David Duncan wrote: > > > > On Apr 5, 2022, at 8:08 AM, 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 entire > > > > > > == 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 > > > > 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.
Yes definately. Alot of other cloud companies don't have the option. I suggest atleast a couple of years.A little inconvinence may give the required push. Maybe only support installation from the everthing iso so those users get that inconvinence? > > _______________________________________________ > 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
