Bug 1077984

Summary: RFE: Do not persistently mount EFI System partition at /boot/efi
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: anacondaAssignee: anaconda-maint
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ahmadsamir3891, anaconda-maint, anaconda-maint-list, candrews, cristian.ciupitu, elliott, g.kaviyarasu, greartes, hugh, johannespfrang, jonathan, noel.mcloughlin, pgnd, vanmeeuwen+fedora, william, zbyszek
Target Milestone: ---Flags: pgnd: needinfo? (anaconda-maint)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1507536 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1507536    

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

Comment 6 D. Hugh Redelmeier 2022-07-19 06:27:21 UTC
I still have this problem on CentOS 7.
Here's a different view of the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=1991228

Comment 7 Fedora Admin user for bugzilla script actions 2023-07-26 12:05:18 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 8 pgnd 2024-03-12 12:47:19 UTC
> Reported: 	2014-03-19 03:35 UTC

@ #fedora-devel, just confirmed that on clean-install of pre-release F40, /boot/efi is _still_ persistently mounted.

if this _will_ be resolved, can it be?

if _not_, can that be stated here, and this bug closed?