On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
<genodeftest(a)fedoraproject.org> wrote:
>
> > […] and move to uefi only supported boot which
> > has been available on any common intel based x86 platform since atleast
> > 2005.
>
> (U)EFI was not available for the general market in 2005 (except on Apple devices
maybe). It was introduced around 2011.
UEFI support was introduced in Windows Vista, 2007. And it was refined
in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in
the Linux world around 2012. And became a requirement for all new
consumer PC's wanting Windows 10 hardware certification, in 2015.
Server hardware has had more leeway.
> I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, manufactured
around 2010 when (U)EFI was not available. One is new enough to having (U)EFI, but
it's a mess and never worked with Fedora's (U)EFI integration so I was forced to
install it in legacy BIOS mode.
>
> In other words: I think it is too early to drop non-(U)EFI BIOS support.
I think there probably are too many legacy BIOS systems for us to drop
legacy support in the near term.
We might consider:
(a) Revisiting GPT by default. By revisiting that means exploring the
bugs and work arounds. The reason for this is moving toward a
self-describing boot process, and abstracting the low level bootloader
requirements from user space configuration. There's good reasons to
get the user space configuration with Boot Loader Spec support
sufficiently abstracted that we could do a drop in bootloader swap one
day, either for use case specific reasons, or distro wide.
It could be that we can abandon hardware that can't tolerate GPT, if
the benefits outweigh the consequences.
(b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm
not sure about the status of this work though, and if it's intended to
bring legacy BIOS systems forward with a single UEFI approach in a
distribution. Or if the intent was only for development purposes until
native UEFI implementations became more ubiquitous. Would adding this
kind of layer just be asking for more things to maintain,
troubleshoot, test, and break?
https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
DUET would probably be the best shot, but it was removed at the end of
2018 due to the lack of interest and usage[1]. If someone wants to
step up to maintain the DuetPkg module for EDK2, we could start going
down the path of streamlining the boot process in the same way that
has occurred in ARM[2]. We'd also benefit from a relatively consistent
UEFI implementation as EDK2 is built on TianoCore[3], which is also
where OVMF/AVMF used for UEFI on KVM is from.
[1]:
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
[2]:
https://fedoraproject.org/wiki/Changes/ARMv7UEFI
[3]:
https://www.tianocore.org/
--
真実はいつも一つ!/ Always, there's only one truth!