On Tuesday, 05 April 2022 at 16:52, Ben Cotton 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. How is making new installs (and thus re-installs) not removing support entirely? The summary is misleading. > == 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. Have you tried getting more people involved? > It is inevitable that legacy BIOS will be removed in a future release. Future release of what and why is it inevitable? > 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. Which is effectively removing support entirely. > 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. I don't see how this is a compromise. > 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, You could switch from syslinux to grub for installation media as well. > 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). It's not a hard requirement. Fedora runs just fine on slower hardware. I have an x86_64 1.66GHz Atom machine from 2010 which is still perfectly serviceable as a router, just as it was 12 years ago. I expanded its memory, replaced hard drives, and it's still running. It's BIOS-only. I would not appreciate having to throw it away because of this change. I already had to say goodbye to a couple of Atom-based netbooks that were x86 32-bit but still in working condition because Fedora stopped supporting this arch. > 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. ARMv7 retirement is irrelevant to this change, but "the world" hasn't moved on from it except maybe for your part of the world. Please stop generalizing. > 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. I've always understood Fedora's "First" foundation to be "First to implement new features/standards", not "First to stop supporting legacy stuff". If 2020 is the year when no new machines are built with BIOS then give it at least another 10 years for the old hardware to die out. > == 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. All these points are valid (with the exception of migration, which is possible, but difficult). However, I'd argue that now is too early to remove BIOS installation support. This could be revisited in a couple of years, but right now the feedback you're receiving is overwhelmingly negative. > == 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. This change fails to uphold three out of four Fedora foundations and even the fourth one is questionable in this case. I can understand the benefit of reducing maintenance burden, but don't pretend it's to uphold Fedora foundations. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ 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
