[systemd-devel] Unmountable mounts and systemd-fsck at .service conflicting with shutdown.target

Valentin David valentin.david at canonical.com
Thu Jan 5 13:18:49 UTC 2023


Hello,

In Ubuntu Core, we have some mounts that cannot be unmounted until we have
switched root.

To simplify, this looks like that:

/ mounts a ro loop devices backed by /some/disk/some/path/image.img
/some/disk mounts a block device (let's say /dev/some-block0p1)

In this case, /some/disk cannot be unmounted.

We do not want to lazily unmount, we cannot get errors if something fails.
(Unless we had a lazy unmount that would only work when read-only)

We do remount /some/disk read-only on shutdown. And in the shutdown
intramfs, we unmount /oldroot/some/disk.

However, we get an error message with systemd trying to unmount it. While
functionally, it does not matter, it is still very problematic to have
error messages.

Using `DefaultDependencies=no` is not enough. I have tried to be clever and
add some-disk.mount to shutdown.target.wants so it would not try to unmount
it. But systemd got confused with conflicts and randomly kills stop jobs
until there is no conflict.

Debugging it, I have found that this is because some-disk.mount depends on
systemd-fsck at some\x2dblock0p1.service. And systemd-fsck at .service conflicts
with shutdown.target.

I wonder if having conflict on shutdown.target really needed. Could we
remove it? (And also add DefaultDepenencies=no to
system-systemd\x2dfsck.slice) With this, mounts with DefaultDependencie=no
do not get unmounted as part of shutdown.target. (They do during
systemd-shutdown)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230105/95a2d895/attachment.htm>


More information about the systemd-devel mailing list