Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux