rfc: EFI System partition, FAT32, repair and non-persistent mount

[Chris Murphy]

On Mar 19, 2014, at 4:53 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Wed, 19.03.14 13:13, Chris Murphy (lists at colorremedies.com) wrote:
> 
>> I agree, although I go farther. The EFI System partition doesn't
>> scale, isn't resilient, can neither be mirrored nor easily sync'd
>> (multidevice boot). It should be considered a pre-boot and OS
>> installer domain only.
> 
> You know, the ESP is actually FAT, one of the simplest, best-understood,
> most used, and most stable file systems around.

Designed for floppies. Used today because it meets the resource requirements of camera and USB media manufacturers, not because it's good for users or their data. Otherwise it's abandoned. Windows, OS X, iOS, Android bootloaders read their kernels from more modern file systems. Apple's firmware directly reads HFS+ so they're not even reading their bootloader from a FAT fs.

FAT is mainly used for write-mostly or read-mostly use cases, where resilience, permissions, extended attributes, etc. aren't needed, and a small footprint for fs code is.

> Sure, one can always
> break things, but it is simply misguided to believe that this is the
> part that will likely break and that we really really really need to
> stay away from, and not the later parts of the boot that involve grub
> and raid, and yuck.

It actually has broken for me more times in 9 months than all other file system corruptions I've had combined. (The corruptions were caused by crashes and forced power offs, but users have crashes and unplanned power failures.)

In no case did the firmware refuse to load the bootloader, but in a few cases the kernel would not mount the ESP at /boot/efi and since /boot/efi mount failed, the startup failed and I was dropped to an emergency shell. So yes, this is in fact more fragile, it's not some misguided hypothetical.

Aside from the corruption concern, there are regressions in actual functionality by putting the configuration files on the ESP.


> You know, by creating a chain of many steps where you first go for
> the ESP, and then follow that by another boot partition and so on, you
> just make things more complex. 

A chain of many steps?

BIOS->boot.img->core.img->/boot/grub2/i386/normal.mod->grub.cfg

UEFI->grubx64.efi->grub.cfg->grub.cfg

That's fewer steps, even with the second grub.cfg. There's no additional boot partition from what's previously been used either.

> If you want things robust, make them simple. Sure, keep writing to the
> ESP at a minimum, but don't play games of just moving those writes to
> another boot partition that is a lot more fragile. You are not helping
> anyone with that…

Huh? Those writes have been on ext3/4 on Fedora for what, 10 years, up until UEFI? And now they're on FAT16. I'm suggesting moving those writes back to /boot on ext4. How is going back to the way it's been done on BIOS a lot more fragile?


Chris Murphy