On Mi, 25.04.18 10:25, Zbigniew Jędrzejewski-Szmek ([email protected]) 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 ([email protected]) > > 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
