> On Apr 5, 2022, at 8:08 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton <bcotton(a)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: rharwood(a)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...
> >
> > 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...
> >
> > * 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?