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

[Chris Murphy]

On Mar 18, 2014, at 10:13 AM, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Mon, 17.03.14 23:02, Chris Murphy (lists at colorremedies.com) wrote:
> 
>> 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. 
> 
> So, systemd actually contains a logic that will automatically create an
> autofs mount point on /boot for the ESP that has been used for
> booting. This logic is automatically disabled if /boot is non-empty or
> if another partition is listed for /boot in /etc/fstab. This setup makes
> things simple, and avoids mucking with the ESP if it is not actually
> accessed, but still makes it available without any manual mounting. 
> 
> 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. 

It looks like the existence of the /boot/efi line in fstab causes boot-efi.mount job to be created; and x-systemd.automount adds an .automount job while not removing .mount job. The .mount job causes it to be mounted anyway. If this is unintended I can post to systemd list or file a bug.

> 
> Yeah, Fedora really should set passno to 1 for all physical file systems
> it mounts, and that certainly includes the ESP.

I just tested setting it for /boot/efi, marking the volume dirty, and rebooting. It does automatically get fixed so the only change here after all is anaconda to set fspassno to 1. So I filed this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1077917

Strictly speaking, per the fstab man page, fspassno should be 0 for XFS and Btrfs since those file systems don't have an fsck, certainly not a non-interactive one designed to be used at boot time. Systemd is smart enough not to try to run fsck on Btrfs. While xfsprogs installs a "do nothing, successfully" fsck.xfs that gets used at boot.


Chris Murphy