Bug 1077984 - RFE: Do not persistently mount EFI System partition at /boot/efi
Summary: RFE: Do not persistently mount EFI System partition at /boot/efi
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1312498 (view as bug list)
Depends On:
Blocks: 1507536
TreeView+ depends on / blocked
 
Reported: 2014-03-19 03:35 UTC by Chris Murphy
Modified: 2018-04-09 16:33 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1507536 (view as bug list)
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 92721 0 None None None 2019-05-23 04:39:03 UTC

Description Chris Murphy 2014-03-19 03:35:28 UTC
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):
anaconda-21.27-1

How reproducible:
Always


Steps to Reproduce:
n/a


Actual results:
ESP is always mounted to /boot/efi



Expected results:
In /etc/fstab, set the /boot/efi entry mount option to include x-systemd.automount,noauto


Additional info:

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.

Comment 1 Chris Murphy 2015-03-01 20:16:14 UTC
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[1640]: 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
[    53.186942] f21s2.localdomain systemd-fsck[1640]: 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.

Comment 2 David Shea 2016-02-29 14:26:29 UTC
*** Bug 1312498 has been marked as a duplicate of this bug. ***

Comment 3 Noel McLoughlin 2016-03-05 15:54:38 UTC
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.

Comment 4 Chris Murphy 2016-03-05 17:23:48 UTC
(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.

Comment 5 Johannes Pfrang 2017-02-17 17:38:33 UTC
(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.


Source: https://www.freedesktop.org/software/systemd/man/systemd.automount.html


Note You need to log in before you can comment on or make changes to this bug.