Fedora considers deprecating legacy BIOS

Post by bscphil » Thu, Apr 21, 2022, 8:55 PM UTC

Foxboron wrote: post #76

AshamedCaptain wrote: post #64

Earlier quoted context omitted.

They also do this because it is likely that Microsoft will stop signing their bootloaders/kernels with their UEFI CA keys if they allow arbitrary user modules to be loaded (because it would be trivial to abuse those kernels to break Windows' full disk encryption). And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scar…

>And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup. Not really? Several popular Linux distributions simply do not support Secure Boot. Arch Linux is one of them.

Post by Dwedit » Thu, Apr 21, 2022, 9:10 PM UTC

mjg59 wrote: post #25

blueflow wrote: post #4

> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered usi…

- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…

Post by mjg59 » Thu, Apr 21, 2022, 9:25 PM UTC

tremon wrote: post #117

mjg59 wrote: post #40

Earlier quoted context omitted.

The UEFI runtime services provide functionality that is not generically exposed through any other OS environment. Linux could just refuse to provide those runtime features, and things would roughly work[1] - we'd still need to call some UEFI features in the boot stub, but the same is true of BIOS (look at what the 16-bit code does in terms of obtaining information that the kernel uses after init). If you want to drop…

can efivarfs still be accessed after booting with efi=noruntime? If so, I might add that on my systems and see if anything breaks.

Post by mjg59 » Thu, Apr 21, 2022, 9:29 PM UTC

userbinator wrote: post #123

mjg59 wrote: post #31

My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now.…

Linux works Just Fine with basically all of them. Do you remember this? https://news.ycombinator.com/item?id=11008449

Post by dralley » Thu, Apr 21, 2022, 9:43 PM UTC

spicybright wrote: post #126

anthk wrote: post #68

Earlier quoted context omitted.

You can use several GNU/Linux distros which support BIOSes, even libre ones.

I agree, and that's the strength of linux, but here's a slight devils advocate: If someone is heavily invested into RH for their BIOS only infra, this could be an issue for them. I'm sure there's large operations that would need fixing up if these change happens. Not that RH is obligated to cater fully to that crowed of course. But 10 years is a bit silly, especially with how expensive hardware is now due to covid. A…