Live data from Hacker News

Fedora considers deprecating legacy BIOS

lwn.net

31–40 of 233 posts

Re: Fedora considers deprecating legacy BIOS

#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. The biggest concern I have is around cloud, where many providers still don't offer UEFI support.

I was on the Fedora technical committee in the past, and if I were still there I feel like I wouldn't go for this now. But I've also been very marginally involved in Fedora in recent years, and I don't think I have a good sense of what the tradeoffs are here. There are legitimate points where it's reasonable to say goodbye to the past, and maybe this is one of them.

Re: Fedora considers deprecating legacy BIOS

#32
UEFI emulation is a thing.

For people with legacy-only firmware systems, you too can run UEFI on lazy cloud providers and legacy hardware. I do this on my 14 year old dell laptop just so that all my x86_64 systems have the same boot efistub linux kernel images. All you need is to use one of the EDK DUET bootloader builds such as BootDuet¹, or for an easier user experience CloverBootloader². Only complaint is secureboot emulation can be a pain. But I imagine with Windows 11 around the corner requiring TPMs (which might require emulation on older hardware that doesn't have it) and secureboot, UEFI firmware emulators with these feature will probably get more popular and more accessible.

¹ https://github.com/migle/BootDuet

² https://github.com/CloverHackyColor/CloverBootloader

Re: Fedora considers deprecating legacy BIOS

#33
post #12

Earlier quoted context omitted.

What replacement do you propose, then? Especially what replacement do you propose that works with the kind of typical hardware that non-specialty linux distros like Fedora want to support? Intel systems make up a large chunk of the hardware Fedora is used on, and as far as I can tell they're all-in on EFI. So Fedora has to use EFI to be able to boot on Intel systems.

I don't. I'm waiting for something else, until then, we'll stick with BIOS. Supporting EFI means implementing more legacy cruft than we already have with BIOS.

This is literally not an option - systems have shipped without BIOS compatibility for a long time now, so refusing to support UEFI is just not an option.

Re: Fedora considers deprecating legacy BIOS

#34

Oh god. So after Windows drops support basically for any PC that is 4 years old, a Linux distribution entertains the idea to follow closely and drop support for any PC that is 10 years old? Is this corporate influence? I cannot believe BIOS boot support is even close to the amount of code required for UEFI boot. Before you say "UEFI is much older than 10 years old", please remember that UEFI only started being a defa…

[dead]

Re: Fedora considers deprecating legacy BIOS

#35

Fedora is often the first distro to adopt radical changes like this and then all the other distros follow and then everyone has to live with their decisions, which often turn out to be made too soon. Not looking forward to having to deal with this one.

it's not really happening, or at least not yet. I don't see why this even got posted the way it was.

Re: Fedora considers deprecating legacy BIOS

#36
post #33

Earlier quoted context omitted.

I don't. I'm waiting for something else, until then, we'll stick with BIOS. Supporting EFI means implementing more legacy cruft than we already have with BIOS.

This is literally not an option - systems have shipped without BIOS compatibility for a long time now, so refusing to support UEFI is just not an option.

No post body was provided.

Re: Fedora considers deprecating legacy BIOS

#37

Oh god. So after Windows drops support basically for any PC that is 4 years old, a Linux distribution entertains the idea to follow closely and drop support for any PC that is 10 years old? Is this corporate influence? I cannot believe BIOS boot support is even close to the amount of code required for UEFI boot. Before you say "UEFI is much older than 10 years old", please remember that UEFI only started being a defa…

Look, even if RHEL 10 gonna drop UEFI support maybe sometime in the future, there's gonna be some retro enthusiats who would happily fork it with BIOS support returned.

Also, why are you so focused with corporate decision of a distro that is obviously cattered for future devices?

Re: Fedora considers deprecating legacy BIOS

#38
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…

> UUIDs ... endianess is not little, big - its mixed. mixed in the same value

UUIDs do not have any endianness. They are just a sequence of individual bytes.

It's true that some ways of generating UUIDs work by using the bytes of longer numbers, which I can believe use mixed endianness (I don't know them well enough to remember myself). But no one should be relying on that when reading UUIDs back out, except maybe for debugging purposes.

Or does GPT require interpreting the parts of UUIDs? If so, that is the real problem.

Re: Fedora considers deprecating legacy BIOS

#39

Earlier quoted context omitted.

Your point is a bit moot because removing bios support will actually allow the maintainer to stop maintaining the bios parts regardless of the fact some other old things are kept. While actually not removing bios support won't allow you to get rid of the aformentionned MS techs such as fat support. Having said that I think this is a wee bit early.

You made a factual mistake: MBR/BIOS based boot does not depend on a specific filesystem, nor does it depend on a specific executable file format except for the boot sector. You can safely remove FAT support from your kernel config, except when you need it for EFI.

> You made a factual mistake: MBR/BIOS based boot does not depend on a specific filesystem, nor does it depend on a specific executable file format except for the boot sector.

I never said that.

I said removing bios support allows you to remove anything that provides bios support and that choosing to not remove it won't allow you to get rid of the EFI dependencies so it is a moot point to talk about old techs used by EFI.

Re: Fedora considers deprecating legacy BIOS

#40
post #20
post #5

Earlier quoted context omitted.

I don't see why Linux users would care about this. It boots the system, nobody cares it uses some old MS tech.

It doesn't just "boot the system". The full EFI specification includes support for runtime services, i.e. proprietary code that keeps running even after your FLOSS operating system has booted. That's something Linux users should care about: it provides a backdoor for clinging to closed-source drivers on a pretend-open platform. There's already been proof-of-concept EFI viruses, it's only a matter of time until the fi…

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 all access to runtime services after kernel boot, you can by simply passing efi=noruntime to the kernel arguments.

[1] Some features would be broken, like recognising whether the system had booted successfully

Post reply on HN