[systemd-devel] automount EFI system partition to /efi fails

Discussion:

Chris Murphy

2018-04-25 00:47:24 UTC

https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
*The ESP used for the current boot is automatically mounted to /efi (or
/boot as fallback),*

systemd-238-7.fc28.1.x86_64

I've commented out the /boot/efi entry in /etc/fstab and reboot but the ESP
doesn't get mounted to /efi or /boot or /boot/efi.

Full journal with systemd.log_level=debug.
https://drive.google.com/open?id=1b4Lfd0HurX4Z68T1jAHYMC0wy51tQwtk

I get a couple of confusing items:

[ 3.971099] f28h.local systemd-gpt-auto-generator[476]: /efi already
populated, ignoring.
[ 4.102022] f28h.local audit[476]: AVC avc: denied { read } for
pid=476 comm="systemd-gpt-aut" name="efi" dev="nvme0n1p9" ino=3999777
scontext=system_u:system_r:systemd_gpt_generator_t:s0
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

It's definitely empty. But maybe it's due to the avc. chcon fails to set
the type to systemd_gpt_generator_t which itself gives me an avc.

Apr 24 18:42:49 f28h.local audit[4486]: AVC avc: denied { relabelto } for
pid=4486 comm="chcon" name="efi" dev="nvme0n1p9" ino=3999777
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:systemd_gpt_generator_t:s0 tclass=dir
permissive=0

Next

[ 6.291607] f28h.local systemd[715]: Followed symlinks /efi â /efi.
[ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
[ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
[ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
[ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
read-only.
[ 6.316442] f28h.local systemd[724]: Followed symlinks /efi â /efi.
[ 6.316472] f28h.local systemd[724]: Applying namespace mount on /efi
[ 6.316505] f28h.local systemd[724]: Successfully mounted /efi to /efi
[ 6.323415] f28h.local systemd[724]: Remounted /efi read-only.
[ 6.354865] f28h.local systemd[753]: Followed symlinks /efi â /efi.
[ 6.354895] f28h.local systemd[753]: Applying namespace mount on /efi
[ 6.354925] f28h.local systemd[753]: Successfully mounted /efi to /efi
[ 6.381654] f28h.local systemd[753]: Remounted /efi read-only.
[ 6.489023] f28h.local systemd[762]: Remounted /sys/firmware/efi/efivars
read-only.

And some additional repetitions but no avcs. So I'm not sure what the
problem is.

--
Chris Murphy

Zbigniew Jędrzejewski-Szmek

2018-04-25 08:10:17 UTC

Permalink

Post by Chris Murphy
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
*The ESP used for the current boot is automatically mounted to /efi (or
/boot as fallback),*
systemd-238-7.fc28.1.x86_64
I've commented out the /boot/efi entry in /etc/fstab and reboot but the ESP
doesn't get mounted to /efi or /boot or /boot/efi.

gpt-auto-generator cannot mount anything to a nested directory,
because when it's running the outer mount (/boot in this case) will
not be done yet, hence it cannot check if /boot/efi is a directory. So
by design it will only consider /efi and /boot as the targets.

Post by Chris Murphy
Full journal with systemd.log_level=debug.
https://drive.google.com/open?id=1b4Lfd0HurX4Z68T1jAHYMC0wy51tQwtk
[ 3.971099] f28h.local systemd-gpt-auto-generator[476]: /efi already
populated, ignoring.
[ 4.102022] f28h.local audit[476]: AVC avc: denied { read } for
pid=476 comm="systemd-gpt-aut" name="efi" dev="nvme0n1p9" ino=3999777
scontext=system_u:system_r:systemd_gpt_generator_t:s0
tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0
It's definitely empty. But maybe it's due to the avc. chcon fails to set
the type to systemd_gpt_generator_t which itself gives me an avc.

It's possible that this is the cause. From the AVC we don't see the name,
but we know it's a directory and read() fails on it. Failure to list the
directory will cause gpt-auto-generator to consider the directory busy,
which would lead to the "/efi already populated" message.

https://github.com/systemd/systemd/pull/8812 has a patch to improve
logging in this case.

Zbyszek

Post by Chris Murphy
Apr 24 18:42:49 f28h.local audit[4486]: AVC avc: denied { relabelto } for
pid=4486 comm="chcon" name="efi" dev="nvme0n1p9" ino=3999777
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:systemd_gpt_generator_t:s0 tclass=dir
permissive=0
Next
[ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
[ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
[ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
[ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
[ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
read-only.

It looks like /efi does get mounted. What mounted it?
Zbyszek

Lennart Poettering

2018-04-25 09:10:54 UTC

Permalink

Post by Chris Murphy
[ 6.291607] f28h.local systemd[715]: Followed symlinks /efi → /efi.
[ 6.291643] f28h.local systemd[715]: Applying namespace mount on /efi
[ 6.291671] f28h.local systemd[715]: Successfully mounted /efi to /efi
[ 6.294820] f28h.local systemd[715]: Remounted /efi read-only.
[ 6.314602] f28h.local systemd[715]: Remounted /sys/firmware/efi/efivars
read-only.

It looks like /efi does get mounted. What mounted it?

That's misleading I figure. That message is probably caused by
ProtectSystem=yes or ProtectSystem=full being set for some system
service. In that case systemd will mount /efi and /boot read-only for
the specific service, but leave / writable. And for that to work it
synthesizes a bind mount point for /efi and /boot within the service's
mount namespace, the logging about which you see above. It hence
doesn't mean /efi or /boot is a mount point on the host.

Lennart

--
Lennart Poettering, Red Hat

Zbigniew Jędrzejewski-Szmek

2018-04-25 10:25:54 UTC

Permalink

Post by Lennart Poettering

It looks like /efi does get mounted. What mounted it?

Even if /efi is empty? We should probably skip the mount point in that
case as a minor optimization.

Zbyszek

Lennart Poettering

2018-04-25 10:57:15 UTC

Permalink

Post by Zbigniew JÄdrzejewski-Szmek

Post by Lennart Poettering

It looks like /efi does get mounted. What mounted it?

Even if /efi is empty? We should probably skip the mount point in that
case as a minor optimization.

Yupp, if it exists it's turned into a read-only mount point.

Not sure if it's worth optimising this corner case, in particular as
while the thing might be empty initially it might not be later on, and
hence we should probably protect those future files too.

Lennart

--
Lennart Poettering, Red Hat

Chris Murphy

2018-04-25 19:24:57 UTC

Permalink

What happens if /efi does not yet exist? I created it normally 'sudo
mkdir /efi' before modifying /etc/fstab to comment out /boot/efi line.

So far as I know, installers don't create /efi (Fedora's installer
does not) so that would be a needed feature. And then also things that
modify /boot/efi need to be modified to use /efi instead. Some of this
is abstracted with symlinks, e.g. Fedora uses symlink grub2-efi.cfg ->
../boot/efi/EFI/fedora/grub.cfg which is how grubby modifies it, but
that can be changed to grub2-efi.cfg -> ../efi/EFI/fedora/grub.cfg -
the bigger change is with the bootloader binaries needing updating,
those packages have to know to look at both locations for the
foreseeable future. Not too difficult, just a matter of doing it.

---
Chris Murphy

Chris Murphy

2018-04-25 19:36:22 UTC

Permalink

Also filed an selinux-policy bug to support /efi

https://bugzilla.redhat.com/show_bug.cgi?id=1571962

---
Chris Murphy

Lennart Poettering

2018-04-26 11:23:43 UTC

Permalink

Post by Chris Murphy
What happens if /efi does not yet exist? I created it normally 'sudo
mkdir /efi' before modifying /etc/fstab to comment out /boot/efi line.

Nothing. The generator that establishes this automount point becomes a
NOP unless:

1. /efi exists
2. /efi is empty
3. There's no mount listed for it in /etc/fstab

Hence, if you want to make use of the automatic ESP mounting logic,
then simply create /etc and all should be good.

Post by Chris Murphy
So far as I know, installers don't create /efi (Fedora's installer
does not) so that would be a needed feature. And then also things that
modify /boot/efi need to be modified to use /efi instead. Some of this
is abstracted with symlinks, e.g. Fedora uses symlink grub2-efi.cfg ->
../boot/efi/EFI/fedora/grub.cfg which is how grubby modifies it, but
that can be changed to grub2-efi.cfg -> ../efi/EFI/fedora/grub.cfg -
the bigger change is with the bootloader binaries needing updating,
those packages have to know to look at both locations for the
foreseeable future. Not too difficult, just a matter of doing it.

The automatic /efi magic is an offer to distributions, that allows
them to remove any kind of mount setup during distro install, and
exposes exceptionally safe access to the ESP (because it is umounted
shortly after every access though still appears mounted
continously). However, it's really just that: an offer. Fedora doesn't
use that by default last time I looked, though I wish it would. I
guess this needs a champion who pushes this through the fedora changes
bureaucracy.

I'd recommend Fedora to create /efi at boot, and then maintain a
compat symlink /boot/efi → ../efi to maintain compatibility with the
status quo ante.

If fedora were to make that change, I figure some RPM postinst script
would have to rearrange things roughly like this:

```sh
sed -i -e '/\/boot\/efi/d' /etc/fstab
mkdir /efi
umount /boot/efi
rmdir /boot/efi
ln -s ../efi /boot/efi
```

Lennart

--
Lennart Poettering, Red Hat