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

171–180 of 233 posts

Re: Fedora considers deprecating legacy BIOS

#171

Post by babypuncher »

speeder wrote: post #111
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…

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

That may have more to do with Nintendo's implementation. The exFAT support that was added to the Linux kernel a few years ago has been fine.

Re: Fedora considers deprecating legacy BIOS

#172

Post by StillBored »

tremon wrote: post #17
faho wrote: 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.

OpenFirmware: https://en.wikipedia.org/wiki/Open_Firmware Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification. Dynamic hardware enumeration is performed by every OS anyway, the only hardware that must be initialized is the bootloader/kernel storage. For the x86 platform, this could be implemented via coreboot (libreboot always reads to me as lib-reboot…

"Many systems get by just fine with a minimal ELF or multiboot loader and a firmware-provided devicetree specification"

Not really, none of those ecosystems has a fraction of the device variation that x86 has. When they do (arm) its a giant mess of incompatibility and non working hardware. Modern DT's are basically still tied to the linux kernel the same way that the old arm/platform descriptions tied firmware id's to individual kernel configurations. Which is why the answer to so many arm problems is "match your DT to the kernel revision", god help you if your trying to multiboot a *bsd/etc as well.

PS: Openfirmware is basically dead, that might have been a valid answer in 1998, but even IBM/etc provide alternative boot mechanisms for linux/PPC at this point. The only thing that comes close to a current replacement is UEFI.

Re: Fedora considers deprecating legacy BIOS

#173

Post by babypuncher »

StillBored wrote: post #170
jordemort wrote: post #112

Earlier quoted context omitted.

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

Well splitting hairs, it mandates that everyone support FAT, individual system+OS vendors can add their own filesystems, but then its vendor lock. So, just do FAT and be done with it. Adding other filesystems is just a waste of time because the ESP only needs to store a half dozen files or so. 13.3.1.1: "The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system"

I think FAT is a fair baseline. It can be implemented in a few dozen lines of code. Support for it is ubiquitous. It is not encumbered by any active patents. All the alternatives I have seen proposed are both considerably more complex and not ubiquitously supported.

Re: Fedora considers deprecating legacy BIOS

#174

Post by StillBored »

chasil wrote: post #90
zozbot234 wrote: post #48

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] LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.

I believe that btrfs can be whole-disk and avoid partitions entirely, which would drastically simplify things. The only snag is swap, which I don't believe can be on a subvolume. vgchange is a struggle for me, from the first time I saw it in HP-UX.

Most (all?) linux filesystems work just fine against raw devices. They are simply unaware of the difference. The larger problem is firmware trying to find partition tables/etc in the middle of a filesytem, but even then its mostly a non issue because random data doesn't tend to look like partition tables or MBRs.

Re: Fedora considers deprecating legacy BIOS

#175

Post by StillBored »

asveikau wrote: post #159
chasil wrote: post #90

Earlier quoted context omitted.

I believe that btrfs can be whole-disk and avoid partitions entirely, which would drastically simplify things. The only snag is swap, which I don't believe can be on a subvolume. vgchange is a struggle for me, from the first time I saw it in HP-UX.

> The only snag is swap, which I don't believe can be on a subvolume. Linux can make swap a regular file, even. It doesn't need to be a partition. Google result shows: https://wiki.archlinux.org/title/swap#Swap_file

And its something you want to do for security reasons anyway, since linux by default isn't encrypting swap partitions. Putting swap on an LUKs encrypted partition is a bit of a PITA but allows one to hibernate/resume without fear that ones private keys end up in plaintext stored on a disk.

Re: Fedora considers deprecating legacy BIOS

#176

Post by StillBored »

blueflow wrote: post #16
faho wrote: 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.

Let me take a moment and point out, unless your using hardware from Others have pointed out that the CSM is no longer being shipped. The CSM is the "Compatibility Support Module" and its a UEFI shim driver that adds the legacy bios INTx operations to a UEFI implementation.

So, most people booting in BIOS mode on hardware built in the past 15 years or so are actually running UEFI with an extra shim.

Re: Fedora considers deprecating legacy BIOS

#177

Post by StillBored »

superkuh wrote: post #166
jeffbee wrote: post #160

Earlier quoted context omitted.

I have a UEFI system right here under my desk that provides legacy BIOS services for running option ROMs, video cards, SCSI host bus adapters, network adapters, anything. It even scans out their legacy video outputs in a little window. There's nothing incompatible between UEFI and legacy option ROMs. Perhaps you are thinking of Secure Boot.

>Perhaps you are thinking of Secure Boot. Nope. I think there must be a miscommunication here so I'll be more explicit. If you have CSM/BIOS mode on your UEFI default motherboard and you set it to CMB/BIOS mode of course you can run BIOS based video cards. But if you switch your mobo to UEFI boot (say, because you want to run future Fedora, or maybe boot off an nvme storage device) you can't use your BIOS firmware vi…

"you can't use your BIOS firmware video cards"

Actually you can, you just don't get firmware boot support. Plenty of those boards work just fine in linux/etc because they reprogram the entire board using AtomBios/etc when the ati/nouveau/etc drivers load. The Arm/PPC/riscv people are all running the same PCIe boards as everyone else, and outside of a few cases they are doing just fine not running the x86 option roms.

Re: Fedora considers deprecating legacy BIOS

#178

Post by qwerty456127 »

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 hasn't been widely adopted by firmware manufacturers either.

Although very complex and very undocumented, NTFS has actually been adopted very widely and quite reliably. Most of the pre-smart TVs and set-top-boxes can read FAT and NTFS USB drives which makes NTFS the only choice if you want movies exceeding 4 GiBs.

Re: Fedora considers deprecating legacy BIOS

#179

Post by ridgered4 »

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.

libvirt/kvm sort of supports it, unless you want to use snapshots I guess. https://bugzilla.redhat.com/show_bug.cgi?id=1881850

That bug appears to be a duplicate, I use legacy bios type for all my VMs to get around this since it's been a problem for at least 5 or more years.

Re: Fedora considers deprecating legacy BIOS

#180

Post by AshamedCaptain »

qwerty456127 wrote: post #178
Macha wrote: post #93

Earlier quoted context omitted.

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 hasn't been widely adopted by firmware manufacturers either. Although very complex and very undocumented, NTFS has actually been adopted very widely and quite reliably. Most of the pre-smart TVs and set-top-boxes can read FAT and NTFS USB drives which makes NTFS the only choice if you want movies exceeding 4 GiBs.

In fact NTFS is available on most commercial UEFI implementations. You can use NTFS to format your Windows install pendrive...
Post reply on HN