On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann > <genodeftest@xxxxxxxxxxxxxxxxx> 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! _______________________________________________ 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
