Fedora 39 Wants To Ensure Your ESP Is Big Enough

[phoronix]

Phoronix: Fedora 39 Wants To Ensure Your ESP Is Big Enough

The latest feature planning around Fedora 39 for releasing later this year is around ensuring your EFI System Partition (ESP) is large enough for new functionality moving forward...

https://www.phoronix.com/news/Fedora-39-Bigger-ESP

[direc85]

As a happy Linux user, former sad Windows user, I have a 1GB ESP partition in every PC I have. Lets me have a kernel or three with fallbacks. We have space, we can use it! Even with with 128GB SSD, it's less than one per cent, so I don't really get the undershooting. Okay, 1GB is a bit large, but at least I don't ever* have to rebuild it bigger.

[chuckula]

How about we stop requiring a stupid FAT32 partition to exist in the first place and get a smart solution that can work with any modern Linux filesystem?

Incidentally, on my 100% modern Arch install I just need a little auto-generated stub file from GRUB and the rest of the partition is empty.

[rhysperry111]

How about we stop requiring a stupid FAT32 partition to exist in the first place and get a smart solution that can work with any modern Linux filesystem?

Incidentally, on my 100% modern Arch install I just need a little auto-generated stub file from GRUB and the rest of the partition is empty.

To be fair, I think that it's perfectly reasonable to use a filesystem like FAT32 for this purpose. It needs to be loaded by the UEFI, so keeping it simple is key. Adding modern filesystems would add unnecessary complexity to firmware

[holunder]

As a happy Linux user, former sad Windows user, I have a 1GB ESP partition in every PC I have. Lets me have a kernel or three with fallbacks. We have space, we can use it! Even with with 128GB SSD, it's less than one per cent, so I don't really get the undershooting. Okay, 1GB is a bit large, but at least I don't ever* have to rebuild it bigger.

Not smart, since any random Windows update/upgrade can wipe your ESP partition with your Linux kernel fuss. Only an option on Linux-only PCs.

[Mitch]

To be fair, I think that it's perfectly reasonable to use a filesystem like FAT32 for this purpose. It needs to be loaded by the UEFI, so keeping it simple is key. Adding modern filesystems would add unnecessary complexity to firmware

What's funny is that they often use Fat for other uses when they need to fit a filesystem's code/drivers into very limited space. An example is when the community makes firmware for certain older gaming consoles, they'll often pick Fat for its tiny footprint. And IIRC, they usually to override some things just to fit the tiny Fat code there, so the console often can no longer read CDs, DVDs, or its original propriety storage.


All that said, it seems like it would be nice to push the envelope at some point to choose something better than Fat, that might even support encryption, multi-disk, and/or checksumming + parity. I know storage hardware does checksumming and error correction too, but I've seen that fall through a few times. And for our safety-critical stuff, more integrity and failsafe options wouldn't hurt, especially when we have hardware running in space or extreme environments where hardware errors could be a greater risk.

[ridge]

I hear they produce ointments for this.

[darkdragon-001]

To be fair, I think that it's perfectly reasonable to use a filesystem like FAT32 for this purpose. It needs to be loaded by the UEFI, so keeping it simple is key. Adding modern filesystems would add unnecessary complexity to firmware

Coreboot+Linuxboot is there to solve this problem: avoid reinventing the wheel over and over again.

[stormcrow]

Not smart, since any random Windows update/upgrade can wipe your ESP partition with your Linux kernel fuss. Only an option on Linux-only PCs.

You're right, it's not smart. But it's not just Windows that can hose the ESP. FAT32 has no provisions for data integrity. None. I can't count the number of times writing to a FAT32 filesystem resulted in corrupted data because the writes were never completed for any particular reason - buffers failed to flush, silent block/cell failures, premature disconnects, and on and on.

The only way you can verify the data in an ESP is correct and unaltered is... wait for it... secure boot. Why? Because even if you do a read check after writing data, there's no guarantee that data was actually written to the storage media till after a power cycle. So you don't really know till you try to reboot or boot. With NTFS, ext4, and other newer generation filesystems you have various mechanisms to be reasonably sure the data written is actually what's on the media before you power cycle.

This is why Windows only writes a small shim to the ESP and the kernel itself remains on an NTFS partition. The kernel can guard itself against incomplete writes and unauthorized user space manipulation. Both are necessary, but if you drop a kernel into the ESP you lose the first, and have to rely on artificial limitations to the files on the FAT32 partition. This is where Pop_OS (which does this same thing, plus has no way to use SB to verify integrity because it doesn't support SB) and Fedora are failing to ask the always pertinent question: "What can possibly go wrong?" and taking the answer seriously by examining the technical characteristics and gotchas of FAT32 (which is required by UEFI but that doesn't mean you can't work around, rather than embrace its glaring inadequacies - which this doesn't.)

[erniv2]

Windows 11 actually defaults to 100MB esp, if you install on an unpartioned drive.

And FAT32 is the only option cause the UEFI has to access it, same reason why usb keys come FAT32 formatted, if you want to do UEFI flashing, booting from usb you need FAT32.

I´m not sure if in some rare cases NTFS is supported as boot device, but i´m 100% sure nobody ever coded any linux filesystem for UEFI.