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

[Chris Murphy]

On Mar 18, 2014, at 6:27 PM, Andrew Lutomirski <luto at mit.edu> wrote:

> On Tue, Mar 18, 2014 at 5:19 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
>> On Tue, 18.03.14 15:07, Chris Murphy (lists at colorremedies.com) wrote:
>> 
>>>> Fedora takes a different approach though, and will mount an explicit
>>>> boot partition to /boot and the ESP to /boot/efi, and do so
>>>> unconditionally without involving autofs.  Fedora could add
>>>> "x-systemd-automount" to the mount options of /boot/efi, and thus
>>>> turning /boot/efi into an autofs too.
>>> 
>>> When I add x-systemd.automount to fstab for /boot/efi, it still gets
>>> mounted on every boot.
>> 
>> Ah, yeah sorry, forgot to mention, you need to also add "noauto" to the
>> line. If it is "auto" we'll still wait for the mount unit to complete.
>> 
>> Basically, combining x-systemd.automount + auto is just a away to speed
>> up boot by fscking in the bg while the mount point is already
>> established. After boot the file system will be mounted as if
>> x-systemd.automount hadn't been used.
>> 
>> Combining x-systemd.automount + noauto however is a way to establish a
>> mount point and only lazily triggering it on access. And that's what you
>> want to use here.
> 
> It seems like 'ls /boot/efi' shouldn't be enough to trigger a mount --
> the poi nt is that /boot/efi should stay unmounted unless there's a
> genuine need to mount it.  So just plain noauto might be good enough
> here (i.e. without the automount).
> 
> I'm usually a fan of giving mountpoints mode 000 to avoid accidentally
> using them when unmounted, but that doesn't really do anything for
> root.

I agree with both points, however it takes additional work first. Otherwise if the ESP isn't (auto) mounted when doing a kernel update today, the updating of /boot/efi/EFI/fedora/grub.cfg will fail. And I believe gummiboot scripts also are stored on the ESP.

My motivation is to avoid complex and fragile configurations, (re)enable resiliently bootable multiple device installs, and not require the user to know esoteric things about UEFI's requirements or differences. UEFI comes with a lot more baggage that's inherently going to burden someone. And I'm arguing in favor of not shifting this burden onto the user.


Chris Murphy