Description of problem: Currently Fedora persistently mounts the EFI System partition at /boot/efi. This is a fragile and unnecessary arrangement. Instead, leverage x-systemd.automount,noauto so that it's dynamically mounted when accessed. This means crashes/power failures won't cause problems if the ESP is unmounted, yet systemd will quickly mount it when accessed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
ESP is always mounted to /boot/efi
In /etc/fstab, set the /boot/efi entry mount option to include x-systemd.automount,noauto
Tested this mount option with fspassno 2, and upon any user command: ls, tree, cp, mv, the volume is immediately mounted. Also tested yum and dnf kernel install, update, and remove, in each case the unmounted /boot/efi was mounted so that the grub.cfg can be updated.
How can this be moved forward? I can consistently reproduce ESP corruption by forced reboot or kernel panic.
[ 4.045750] FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Based on upstream (see also) the corruption is not a kernel bug, it's just the way things are with FAT. The recommendation from kernel and systemd folks is to not persistently mount the ESP.
I've tested mount option 'x-systemd.automount,noauto' with fspassno 1 or 2 (bug 1077917) for ~1 year now, and this mostly prevents the problem while causing no new problems. The result is the ESP is not mounted unless something accesses /boot/efi/ at which time it's fsck'd and then mounted. Even in the case of a dirty bit, the fsck fixes the problem and the ESP is mounted very quickly (less than 1 second).
[ 53.186934] f21s2.localdomain kernel: FAT-fs (sdc1): unable to read boot sector to mark fs as dirty
[ 53.186940] f21s2.localdomain systemd-fsck: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
[ 53.186942] f21s2.localdomain systemd-fsck: Automatically removing dirty bit.
The best way forward is for the ESP to only be mounted on-demand by authorized packages to e.g. update the bootloader. This requires changes to grub2-efi and grubby packages that aren't yet planned, so in the meantime the simplest solution is mount option 'x-systemd.automount,noauto' and passno 1 or 2.
*** Bug 1312498 has been marked as a duplicate of this bug. ***
For complete solution, you could try x-systemd.idle-timeout=1min option also. The idea being the ESP is auto-umounted after some idle period. This would be a good auto-configuration for anaconda installs if it works.
(In reply to Noel McLoughlin from comment #3)
> For complete solution, you could try x-systemd.idle-timeout=1min
Yeah it's a good idea, I think that's a relatively recent option for systemd. I'll add to the machines here and test. Not even /boot should be persistently mounted, but due to improperly nesting /boot/efi, I'm not sure it's reliable to use these systemd mount on demand options for both at the same time.
Really they should be mounted only on demand by whatever has the proper privilege to modify them, and mounted somewhere inside /run/. 99% of the time, /boot/efi and /boot are bootloader domain only, nothing kernel or user space needs access to them except when they're being updated. It's something of a security risk.
(In reply to Chris Murphy from comment #4)
> [ ... ] Not even /boot should be
> persistently mounted, but due to improperly nesting /boot/efi, I'm not sure
> it's reliable to use these systemd mount on demand options for both at the
> same time.
Systemd has automatic dependency detection and resolution that takes care of this problem:
If an automount unit is beneath another mount unit in the file system hierarchy, both a requirement and an ordering dependency between both units are created automatically.