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

Chris Murphy lists at colorremedies.com
Tue Mar 18 05:02:51 UTC 2014


Two feature requests, comments please.

1. EFI System partition is being mounted persistently at /boot/efi, and I'd like to put an end to that because there's no good reason to do it. None of the binaries on it are regularly being updated, and if they are, the volume should be mounted on demand rather than persistently. The grub.cfg on each ESP should be a simple static grub.cfg like this:
# cat /boot/efi/EFI/fedora/grub.cfg
#
# DO NOT EDIT THIS FILE
# THIS FORWARDS TO THE REAL GRUB.CFG
#
{
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 10044fb4-8f90-4ca6-888c-98a0c88169e2
	configfile /boot/grub2/grub.cfg
}

And then we update /boot/grub2/grub.cfg just like on BIOS systems, on a file system that can tolerate some abuse, unlike FAT. It also means there's some chance of resiliently bootable raid on UEFI systems which right now isn't assured because we don't create ESP's on each system disk chosen, let alone have a way of syncing the grub.cfg's on each of those ESPs. Nor a way to mount them all at the same time anyway.

Last, Windows and OS X don't keep their ESP or boot volumes persistently mounted, I don't know what good reason we have for doing this.


2. Right now we aren't doing an fsck on the single ESP we do mount. If we're going to continue to mount it on every boot despite the arguments against doing so, shouldn't /etc/fstab fspassno be set to 1 for /boot/efi? I have experienced ESP file system corruption and /boot/efi wouldn't mount as a result, which hangs the system and eventually drops it to an obscure emergency shell.

Affected by this change are anaconda to set fspassno to 1; dracut to include mkfs.msdos initramfs; and possibly to fsck so that it runs mkfs.msdos with -a which currently it doesn't do, instead it runs it interactively which isn't suitable for boot time fixing. If we don't have the will to be checking and fixing a file system critical for booting, maybe we shouldn't be persistently mounting it rw (back to 1 above)?


3. Currently Fedora anaconda installs result in a FAT16 ESP which also isn't done on Windows or OS X, except for removable media. My reading of the UEFI spec says that on system drives (non-removables), it should be FAT32. I don't know if it's really a problem that we're using FAT16, but figured I'd point it out here in case someone has two cents to add on this. A bug has been filed already.
https://bugzilla.redhat.com/show_bug.cgi?id=1046577



Chris Murphy


More information about the devel mailing list