- FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader that FAT doesn't support?

- Yeah in an ideal universe we wouldn't have to deal with PE binaries and we wouldn't have to deal with the Windows 64-bit calling convention for jumping into the firmware and also we've solved all of this shit and it just isn't a big deal any more. We can look at any platform and complain about the implementation details, but at least this one is better documented than the BIOS interface ever was.

In summary: Linux has to boot on computers that exist, and most computers that exist have UEFI. The Linux community has had the opportunity to make meaningful improvements to the UEFI spec in a way that wasn't true with BIOS. UEFI isn't ideal, but it's better than what came before in this respect.

[1] Partitions could be identified as "Linux", but that gave you no information about what they were or where they should be mounted. Current systemd-driven development has allowed us to define the partition mount point as part of the GPT data, which means they can be automatically mounted in the correct place without static configuration about partition layout

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 independent EFI boot partitions (one for Windows and one for Linux) and use the computer's boot menu too choose which to boot from.

Ideally the whole OS should be just a read-only boot image and a traditional partition should only be used for config/data files IMHO.

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.

Different systems have different constraints. For example, loading the firmware interface on my systems so it can present a boot menu is way, way slower than rEFInd or Grub. And presents an ugly menu in a non-native resolution for my monitors. And doesn't let me override kernel parameters adhocly at boot time if needed (thought it has been a number of years since I have, I'm reluctant to let go of the option).

Pop!Os uses systemd-boot (formerly gummi-boot) by default if you're on an UEFI system, and only falls back to GRUB for legacy bios.

Arch is also much easier to setup on systemd-boot.

The issue is that GRUB still has a very compelling support matrix - it'll work basically everywhere, and with most all configurations. So if you're already running a batteries included distro, where someone else is doing most of the configuration and the downstream systems are hugely variable (old consumer hardware) - then GRUB still makes the most sense.

ExFAT can support those. You could also use the UDF file system.

> I would rather use Ext4 everywhere for everything. Is the problem preventing wide adoption of Ext4 GPL?

The BSDs don't support ext{2,3,4} particularly well, and Linux doesn't support FFS/UFS particularly well. I mean, there's support for these things, but it's far from complete or perfect and it's taken a long time.

It's just a fair amount of effort to implement filesystems well, and there's very little tolerance for errors. Ext4 isn't spectacularly complicated, but it's not exactly a simple FS either. I think that has more to do with lack of support than anything else: lots of effort for not all that much practical benefit.

And ext has plenty of documentation and they haven't implemented that either.

So I think keeping down the software complexity is the more likely method. Down to

1. The limited software investment these companies make (often just buying and reskinning firmware from AMI)

2. The limited space available on the ROMs due to hardware cost savings (e.g. companies have had to drop GUIs or support for less popular APUs to add support for new generations of mainstream CPU in firmware updates)

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.

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

So, not a problem, with the huge advantage FAT can be implemented/validated/etc in a few dozen lines of code.

KISS

LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.

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.

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

The problem is less about linux being capable of encrypting/protecting the swap file and more around being able to assure that is true. So like many Linux kernel issues recently its less technical, more political.

So, as I mentioned previously its entirely possible with off the shelf distro's to enable encrypted swap, the average user just has to choose between hibernate, assuring the swap is secure, and secure boot. Its a bit irritating, but seems to be low priority as the focus seems to be on suspend or hibernate without secure boot.

there's also some limitations, see https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#swapf...

So I'd rather use EXT3 or NTFS because of Journaling, and not FAT.

Right now at Aurora

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.

Ok contrast that with UEFI. There are FAT boot partitions and PE executables and what not. That's a lot more complexity.

The main problem you have is that convincing manufacturers and proprietary OS makers (including Microsoft) to switch to a hypothetical UEFI replacement free of those issues is going to be an impossible task, while UEFI is already here and while not perfect appears to be better than the legacy BIOS boot system.

No. They are not Windows executables. They won’t run under Windows at all for multiple reasons. They are PE executables.

PE is the executable format developed for Windows, and yes, it is backwards compatible with MZ executables, so it has the now-confusing MZ header even though that doesn’t make sense under EFI. It also has some other weird details kind of hardcoded in, like some of the data directories, many of which don’t make that much sense under EFI. Worse, it’s a little weird to parse, with many things being deduced by using known structure sizes combined with offsets specified in fields.

However, PE as a format is totally fine. Good, even. In its purest form, it really doesn’t have that much baggage. It flat out has some advantages over ELF whose symbol table non-sense is notoriously complicated. Not so under PE: explicit table of exports, explicit table of imports. The imports go to specific modules. Symbols don’t conflict. It’s got cruft, but it’s very simple to write a parser or loader, and I’ve done so a number of times before. With PE the runtime linking is handled by whatever OS is running, be it EFI or Windows; none of the INTERP stuff is needed.

Frankly, I’d be OK with using PE on Linux too. When I was a kid, I toyed around with making a binfmt for PE. Of course I didn’t finish (most notably, I never figured out how to do linking, since the ELF binfmt didn’t really do that) but it’s quite straightforward to get the actual loader going.

As for the rest of the grievances… As far as I know, FAT and GPT are only required to be supported by EFI, not required to be used. Some EFI implementations support other filesystems for the ESP (like Apple with HFS+,) and I’ve not used one that won’t happily use an ESP on an MBR.

Starting with the fact they have a dedicated set of "subsystem" values: https://docs.microsoft.com/en-us/windows/win32/debug/pe-form... - the win32 loader won't load anything that isn't the CUI or the GUI Windows one, although the kernel also knows about the native one. You'll just get the "this is not a Windows application" messagebox.

With NASM, you can also override that linker stub. For example save this to a file:

    org 100h
    
    start:
        mov dx, msg
        mov ah, 9
        int 21h
        mov ah, 4Ch
        int 21h

        msg db 'Are you still running DOS in 2022? Wow! 640K enough for you!',13,10,'$'

then if you are using Microsoft's tools you can use LINK.EXE <usual args> /STUB:stub.com and voila, if anyone _happens_ to (try to) your code under DOS, they'll get an amusing message.

If you want it to take up minimum space, use this one:

    org 100h
    
    start:
        mov ah,4Ch
        int 21h

Apparently the header is hardcoded in mingw, but you could easily binary patch it in the resulting executable.

I think I read somewhere you can also remove the stub completely, but I've never tried it.

Edit: for my last comment, yes, you can definitely drop it: https://stackoverflow.com/a/9659538.

Viceversa, it is possible with some loaders to boot BIOS from GPT (not easy-peasy or straightforward but it can be done).

As well, the FAT is only a requisite if there is not an EFI driver for the filesystem, as an example some motherboards and RUFUS provide a NTFS driver that allows booting from NTFS volumes under UEFI.

Still, while in theory GPT and UEFI have a few advantages, there is not in practice (yet) any meaningful reason to remove support to BIOS, though lately a number of notebooks have UEFI firmware only (no CSM aka BIOS), I cannot see how removing an option/choice from a distro can be a good thing.

Hint: download the latest version of Rufus, point it to a windows 11 iso and select the "Extended installation" mode. The result will happily install itself onto an MBR partition.

I performed an upgrade (!) of a windows 10 installation to windows 11 in this manner; I'm writing from this SSD right now.

  PS C:\Users\alexa> $(get-disk | ? {$_.IsSystem}).PartitionStyle; [System.Environment]::OSVersion.Version 
  MBR
  
  Major  Minor  Build  Revision
  -----  -----  -----  --------
  10     0      22000  0

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.

https://en.wikipedia.org/wiki/Universally_unique_identifier#...

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.

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.

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"

So the choice is between adopting it and keeping BIOS indefinitely, or adopting it and at some point in the future dropping BIOS.

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.

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) with a multiboot payload.

That would be a massive step backwards in hardware support.

Like I said: They don't really have the option of not supporting EFI.

Alternatively they can support EFI and OpenFirmware, but that increases the number of supported paths instead of decreasing them.

The distribution needs to do almost nothing to support either EFI or the legacy BIOS or any other booting method.

That is the job of a bootloader package, not of the Linux distribution. For example I am using syslinux as the bootloader for all my computers, while grub is another example of a frequently used bootloader (but which seems to be excessively complex in comparison with syslinux).

I assume that by supporting only EFI Fedora means that they will remove all bootloaders from their installation image, so that the Linux kernel will be launched by its EFI stub.

I do not know about other bootloaders, but an installed syslinux package occupies only a few megabytes, maybe 10 megabytes at most, so deleting it cannot provide much space for anything else.

I cannot see how deleting a bootloader package may be claimed to be a significant simplification for the maintenance effort of the Fedora distribution.

2. They no longer need to support bios booting in the forums - no asking "how do you boot this? Bios, EFI? Have you tried the other?", no telling people "EFI is required for feature X"

3. They no longer need to maintain the bios boot documentation

4. They no longer need to maintain the bios path in the installer/boot media

5. They no longer need to test the bios paths (or hope they don't break and be ashamed if they don't)

6. This makes it easier to switch to a EFI-only default bootloader (instead of Grub 2, which can do both)

Is this massive? No, it's possible to keep maintaining BIOS support. But it's not just freeing space on the package mirrors either.

Grub 2 is complex to configure, but there are other bootloaders that are much easier to configure, e.g. syslinux.

Restricting the boot method to EFI does not reduce the need for documentation in any way.

The user must still be instructed to enter the BIOS setup and verify whether their computer is not configured to boot in legacy mode, which would prevent booting. Also the user must be instructed to enter the BIOS setup even if the EFI mode is used, because the installation media might not boot anyway, because a wrong boot order is configured for EFI booting, and it must be changed.

The most complex part of the installation is not the booting, but identifying the device where Fedora should be installed, which might be needed to be reformatted and repartitioned.

So a lot of documentation is needed in any case, for novice users.

Removing the booting in legacy mode increases the chances that the installation media will not boot without the user having to modify the BIOS setup, so it increases the chances of the user having to search support in the forums.

~~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 is no longer supported. I read that as it being bios-only, but it seems to support EFI?

>Restricting the boot method to EFI does not reduce the need for documentation in any way.

You still need documentation, yes. But you no longer need any documentation for booting with BIOS.

You no longer need to say "X is only supported in EFI, if you boot via BIOS you need to do Y" or anything like that, and keep those parts updated.

The part of the docs that says "To boot EFI, do X. To boot BIOS, do Y" can be cut down to "To boot Fedora, ensure X".

That is a reduction in the amount of documentation.

No other bootloader is needed.

I think you're seriously underestimating the amount of effort the bootloader and hardware enablement teams who work on Fedora put in to making _systems boot Linux at all_.

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.

However, the vast majority of server or desktop motherboards and of laptops still have the option for legacy BIOS booting, even if the option may be difficult to find in the BIOS menus.

I have about a dozen servers, desktops and laptops and I have configured all of them to use legacy BIOS booting, because EFI booting does not have any advantage, only disadvantages.

It would have been very easy to replace the ugly legacy BIOS booting method with a simple and clean method for booting, but unfortunately those who made the EFI specification have failed to achieve this goal.

For an already installed system it doesn't really matters, so the point is moot here.

But for the new systems setup I would always prefer a UEFI (with or without SecureBoot) because it allows to expose the HID management of the onboard/expansion board controllers, a proper way to return to the management/boot menu in the case of the failed boot.

Sure, it doesn't always work good, but neither BIOS/CMS.

Nevertheless, the option to enable the legacy BIOS booting can be quite hard to find in the BIOS menus, which may deceive many into believing that a system does not support legacy BIOS booting, even when it actually does support it.

On work computers belonging to a company, the BIOS configuration may be locked, so it might not be possible for the users to enable legacy BIOS booting.

> Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora's "First" objective.

You may not have seen many computers yet without legacy BIOS compatibility but this is going to be the norm for new computers very soon.

However, it was a model launched in the second half of 2020. It is indeed possible that the models introduced since 2021 might omit the legacy BIOS booting support.

Never noticed until I wanted to boot memtest.

It’s possible that I missed it, but Google results didn’t look promising either.

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.

ME security vulnerabilities cannot be fixed in many cases, and it is an intolerable risk for some.

If you insist on a system that does not run ME at all, then the best you can run is a Core 2 Quad x9650 on BIOS.

Be mindful of what you are losing when you deprecate that machine.

That is done by the maintainers of the bootloader packages.

What Fedora presumably intends is to remove all bootloader packages from the installation image.

In that case, the Linux kernel can be booted only by using its included EFI stub.

One less package in the installation image might be claimed to imply less maintenance work for Fedora, but in any case such maintenance work has nothing to do with the work done for maintaining legacy code.

The mixed-endianness of GUIDs sounds annoying, but also easily worked around. It seems worth putting up with for the resiliency offered having the GPT duplicated at the beginning and and end of the disk.

I'm not sure the UEFI system partition has any practical need for anything newer or more complex than FAT. It is a very simple file system for which support is ubiquitous, and is far more capable than an MBR boot sector.

The EFI executable format being derived from Microsoft does not seem like an inherent problem, unless you can point out some meaning limitation it has compared to an alternative. However I do not know enough about binary executable formats to debate the merits of PE over ELF, so I could be missing something.

It seems to me the benefits of UEFI far outweigh the negatives here. And with UEFI now being ubiquitous in consumer and commercial hardware for about a decade now, I do not think a bleeding edge distro like Fedora dropping BIOS/MBR is a huge deal.

I've always wondered why it was required that my EFI partition be FAT. I've had systems where that partition has gotten messed up and required an fsck from a recovery boot, and it seemed like it should be possible to either do that automatically in some way, but being able to use a filesystem that self-corrects would be nice too (although maybe overkill for the 1 GB or whatever I give it). I guess maybe it would only be possible to perform the fsck if I booted from a different partition, which then could develop the same issue. This does make me wonder how silly it would be to have a duplicate boot partition on each of my machines that I only mount to sync over changes to the real one so I could avoid needing to grab my flash drive when stuff like this happens...

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

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.

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.