Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fedora considers deprecating legacy BIOS

lwn.net

Post reply on HN
Print view View original

101–110 of 233 posts

Re: Fedora considers deprecating legacy BIOS

#101

Post by lynguist »

lynguist wrote: post #98

According to Wikipedia, Intel’s 945 chipset for Core 2 processors ships with UEFI. This was originally released in 2006. Note that Google Chrome which is the web browser with the highest adoption rate requires a CPU with SSE3 support which was introduced in 2004. Which platform older than a Core 2 can even run the latest operating systems? The very latest Pentium 4 range (2004-2006)? So we would just be dropping supp…

I found that the latest BIOS only devices were released in 2013 which are based on the AMD Bobcat processor (AMD’s version of Intel Atom). I wouldn’t know what operating system to run on those systems.

Re: Fedora considers deprecating legacy BIOS

#102

Post by AshamedCaptain »

martijnvds wrote: post #11
raverbashing wrote: post #2

Yeah it seems like a bad idea Especially because of: > Fedora is also installed on cloud servers and virtual machines of various sorts, some of which do not support anything other than booting via BIOS. The proposal noted that the time of the 2020 discussion, Amazon's AWS did not support UEFI, but that has changed. Marc Pervaz Boocha pointed out that many virtual private server (VPS) providers do not support UEFI, gi…

It's easy to use EFI when virtualizing things locally. libvirt/kvm supports it, Hyper-V supports it, Virtualbox supports it, ESXi supports it.

As far as I can see, only Hyper-V enables it by default as of today; this means most of the VMs being created _right now_ we can assume to be BIOS rather than UEFI.

Re: Fedora considers deprecating legacy BIOS

#103

Post by viraptor »

bigpod wrote: post #71

while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. This is to prevent mirriad of issus BIOS brings including its horrible MBR. GPT is million times better and for someone who dual boots on many machines (and has a drive with 14 different operating systems as a test) to all you legacy BIOS and MBR fans MBR doesn…

I agree in general, but not with this: "It wasnt windows's fault its just that its update utility had to overwrite a part of MBR". If they cared, they could spend some time to design / document a nice way for systems to redirect to the next entry. They could've used grub and chainload. They could've invited others to collaborate. It was very much in MS interest not to care and I totally blame them for doing just that.

Re: Fedora considers deprecating legacy BIOS

#104

Post by quietbritishjim »

blueflow wrote: post #42
quietbritishjim wrote: post #38

Earlier quoted context omitted.

> 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 fo…

Its relevant for converting them from and to their string representation. https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Interesting link, thanks, I wasn't aware of that. The link seems to suggest that the odd mixed-endian string representation ("Variant 2") is now quite rare.

With the one that's more common ("Variant 1"), I'd say that I *slightly* disagree that representing the byte sequence 99,aa,bb,cc as 99aabbcc is "big endian". If you don't philosphically think of the latter as a number, then it's just the bytes written out compactly. But I do see that if you think of it as a number then it's big endian, especially if you're distinguishing from variant 2.

Re: Fedora considers deprecating legacy BIOS

#105

Post by adrian_b »

usrn wrote: post #88
faho wrote: post #86

Earlier quoted context omitted.

>Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux. ~~Yes but syslinux is bios-only. So if you have to support EFI too (and you do because there's EFI-only hardware), you now either need to support syslinux and an EFI bootloader , or a bootloader that supports both like Grub 2.~~ Edit: The article seems to suggest that syslinux can be removed if bios boot…

You arguably don't need a bootloader at all with EFI. You could just use the efistub.

Yes, it is easy to make a bootable device that can use either syslinux to boot when legacy BIOS is used or efistub to boot when EFI booting is used, eventually loading the same kernel.

No other bootloader is needed.

Re: Fedora considers deprecating legacy BIOS

#106

Post by mwcampbell »

mjg59 wrote: post #29
blueflow wrote: post #28

Earlier quoted context omitted.

Quoted post unavailable.

I'm responsible for a great deal of the UEFI support on x86 Linux systems. You're absolutely free to have concerns about a lot of the political and social positions I hold, but this is a topic where I am literally a domain expert. If you disagree with me on this subject, present technical arguments.

As a newcomer to this thread, just wanted to say thanks for bringing your domain expertise to this discussion even though you're certainly not obligated to do so. And, though I presume you've been paid for at least some of the work you've done on Linux UEFI support, thanks for that as well. I'm thankful that someone is willing to go to the trouble to make Linux relatively easy to boot and install on modern PCs, though I imagine the desktop Linux space isn't very lucrative.

Re: Fedora considers deprecating legacy BIOS

#107

Post by tremon »

qwerty456127 wrote: post #47
mjg59 wrote: post #25

Earlier quoted context omitted.

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

> what features do you want in the partition that contains your bootloader that FAT doesn't support? Well, I'd love to be able to drop a bunch of 8GB (notably FAT doesn't support files this big) LiveDVD disk images on a bare file system and see them in the computer's built-in boot-menu immediately. I already enjoy the fact I don't need a traditional boot loader (like GRUB) to handle multi-OS as I can have 2 independe…

I can have 2 independent EFI boot partitions and use the computer's boot menu too choose which to boot from.

You don't need 2 EFI boot partitions for this -- you can have multiple boot loaders in the same EFI partition, each with its own entry in the boot menu. In fact, this is how I boot: the default entry boots the linux kernel directly from the EFI partition (some UEFI implementations require the kernel to have a .efi extension, others don't), and I have separate fallback entries for refind and shellx64 in case I need to boot with different kernel parameters.

Re: Fedora considers deprecating legacy BIOS

#108

Post by superkuh »

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.…

You (and they) forget the part where graphics cards play an intimate role in MBR or UEFI boot. And there still innumberable quite functional graphics cards that will never, ever, allow a system to boot under UEFI. GPUs are deeply integrated into the boot up process.

This is easy for IBM/Fedora to forget because GPUs probably don't matter much to them. They just take their intel integrated graphics on their workstation (or server) and go. And other linux devs are probably rich enough to buy a modern GPU.

But it is a huge issue and it'll not have become irrelevant for at least another decade. Not being able to boot MBR will break (and prevent) much more than the Fedora, LWN, or most of the threads here are aware of.

Re: Fedora considers deprecating legacy BIOS

#109

Post by iod »

zinekeller wrote: post #44
iod wrote: post #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 securebo…

> 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. Unfortunately, there's no appetite - there's no point since that in a significant break Windows 11 only runs on new processors that happens to have both UEFI and TPM (not al…

Apparently you can officially just shut off the restriction that forces Windows 11 to only run on new CPUs and the newest TPM by just setting a registry key AllowUpgradesWithUnsupportedTPMOrCPU on install.¹ But I never use Windows and don't plan to start anytime soon, so it's not something that I will try.

¹ https://support.microsoft.com/en-us/windows/ways-to-install-...

Re: Fedora considers deprecating legacy BIOS

#110

Post by zahllos »

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…

I am actually for keeping the legacy scheme around for a good while, mostly because there's plenty of hardware even now that relies on it.

But UEFI is more sane. Bios systems map the first 512 bytes which are both code and partition table into ram. Into that you need to cram enough code to locate stage 2, which I think tended to be located in the alignment space between the MBR and the next sector. Stage 2 once loaded needed enough logic to find and load your boot partition, and load your config from it, parse the kernel list and finally load one of those kernels. I seem to remember grub hard coding where the stage2 actually was, although I might be wrong about that. Either way it was a kinda fragile mess.

Sure, every boot process needs to get enough logic loaded to do the next thing, but with efi this is all taken care of during efis various internal loading phases, nicely located in code on onboard flash where it probably should be. By the time it comes to look for what you want to load, you are already in long mode and we aren't hiding stuff in places not covered by a partition definition. It is kinda annoying they didn't consider a boot filesystem with large enough file storage for big images (exfat, udfs, other reasonable choice, we have the filesystems) but we can cope with that.

The process for detecting bootable partitions and updating boot entries is a lot, lot saner than BIOS systems tend to be. Sure there are details of the design I don't like, and I kinda agree with your points there too, but substitute those for better choices and you still have a reasonable overall framework.

Post reply on HN