automount EFI system partition to /efi fails

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Mi, 25.04.18 10:25, Zbigniew JÄ?drzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> On Wed, Apr 25, 2018 at 11:10:54AM +0200, Lennart Poettering wrote:
> > On Mi, 25.04.18 07:48, Zbigniew JÄ?drzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> > 
> > > > [    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.
> 
> 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