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

111–120 of 233 posts

Re: Fedora considers deprecating legacy BIOS

#111

Post by speeder »

qwerty456127 wrote: post #57
zozbot234 wrote: post #51

Earlier quoted context omitted.

> notably FAT doesn't support files this big ExFAT can support those. You could also use the UDF file system.

But ExFAT lacks the FAT's virtues of being universally supported and royalty-free, yet still is a very dumb FS with no journal (which means unreliable) and no extended attributes (which means data-metadata separation impossible) so I don't see a reason for it to exist anywhere outside severely resource-limited embedded applications. I would rather use Ext4 everywhere for everything. Is the problem preventing wide ado…

Seemly ExFAT is specially unreliable... Nintendo Switch community first advice when you buy one is: If you buy a SD Card with ExFAT, reformat it to FAT, because ExFAT will eventually cause your files to be corrupted...

Re: Fedora considers deprecating legacy BIOS

#112

Post by jordemort »

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…

EFI doesn't actually mandate FAT for the system partition. The system partition can be any filesystem that the firmware supports.

Of course, pretty much all EFI implementations only support FAT, so it's a bit of a moot point; the only one I'm aware of that supports anything else is the one on Intel Macs, which also understands HFS+.

You can find a huge selection of EFI filesystem drivers at https://efi.akeo.ie/ but they're derived from GRUB and hence GPL, so don't expect the likes of American Megatrends to be bundling these any time soon.

Re: Fedora considers deprecating legacy BIOS

#113

Post by vetinari »

Macha wrote: post #93
qwerty456127 wrote: post #57

Earlier quoted context omitted.

But ExFAT lacks the FAT's virtues of being universally supported and royalty-free, yet still is a very dumb FS with no journal (which means unreliable) and no extended attributes (which means data-metadata separation impossible) so I don't see a reason for it to exist anywhere outside severely resource-limited embedded applications. I would rather use Ext4 everywhere for everything. Is the problem preventing wide ado…

NTFS hasn't been widely adopted by firmware manufacturers either. I don't think firmware manufacturers want to spend time implementing support for even the NTFS/ext/APFS era of filesystems, never mind anything newer like ZFS or btrfs.

NTFS was also undocumented, and whatever the ntfs-3g folks or others working on alternate implementation figured out, it was via reverse engineering.

Re: Fedora considers deprecating legacy BIOS

#114

Post by userbinator »

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…

Ironically, the first thing I do is the opposite. BIOS boot has been simple and reliable for decades, and EFI remains a horrible mess.

Remember how some people have had issues with windows destroying booting of linux

The MBR is tiny (you could even write out all the entries on paper as a backup, like I became accustomed to many years ago whenever I partitioned a disk) --- and restoring it is also equally straightforward. I don't even know where to begin with troublshooting EFI's horribly overengineered boot entries and NVRAM variables...

Re: Fedora considers deprecating legacy BIOS

#115

Post by tremon »

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…

to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot.

That's neither here nor there. You can still perform BIOS boots from a GPT-partitioned disk, in fact it works even better: while in MBR mode the stage1 grub loader must be placed in the unused 31kB between the partition table and the first partition start, GPT allows you to explicitly allocate a partition for the stage1 code. This means no more borkage because Windows overwrote an officially unused part of the disk, and the stage1 payload is no longer limited to 31kB.

Point being, your rant has nothing to do with BIOS vs UEFI boot.

Re: Fedora considers deprecating legacy BIOS

#116

Post by GoblinSlayer »

quietbritishjim wrote: post #38
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…

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

UUID is defined as a sequence of 6 integer fields of various sizes. Their conversion to text is fairly straightforward, but serialization to bytes may vary depending on how you do it. "Whatever ends up in memory" is microsoft little endian format.

Re: Fedora considers deprecating legacy BIOS

#117

Post by tremon »

mjg59 wrote: post #40
tremon wrote: post #20

Earlier quoted context omitted.

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…

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

Re: Fedora considers deprecating legacy BIOS

#118

Post by dinosaurdynasty »

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…

> what features do you want in the partition that contains your bootloader that FAT doesn't support?

Atomic updates and not getting corrupted if the power is pulled/lost while the filesystem is being written to.

Re: Fedora considers deprecating legacy BIOS

#119

Post by AreYouSirius »

TZubiri wrote: post #91
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…

This is the incorrect take on the subject. Dual booting is a feature used by less than one in ten thousand users. Obsoleting BIOS will obsolete millions of hardware pieces.

No post body was provided.

Re: Fedora considers deprecating legacy BIOS

#120

Post by userbinator »

Leave things as they are. Code continues to rot.

What is this ever-present BS about "rot"!? Why do people think continual changes are even needed? Code should become more stable over time, an ideal that I wish much more software would follow. The way BIOS boot works has basically remained unchanged ever since the first IBM PC, and it's incredibly simple. Linus Torvald's opinion of EFI is worth reading:

https://yarchive.net/comp/linux/efi.html

7C00h forever! ;-)

Post reply on HN