]> git.ipfire.org Git - thirdparty/mkosi.git/commit
sandbox: Don't create shared propagation peer group main
authorDaan De Meyer <daan@amutable.com>
Fri, 31 Jul 2026 17:58:50 +0000 (19:58 +0200)
committerJörg Behrmann <behrmann@physik.fu-berlin.de>
Fri, 31 Jul 2026 19:58:28 +0000 (21:58 +0200)
commit33d17b2b92b87b27842767df14c362e13023f735
treeec821422639f6da42f1f51c312a62728ff387760
parenta078088f8e344b51e66fe41c806d1b6cb32fe1b1
sandbox: Don't create shared propagation peer group

Shared mount propagation always causes extremely hard
to debug bugs. For example, if I do the following mounts

/my/rootfs/path => /buildroot
/dev => /buildroot/dev
/my/rootfs/path => /buildroot/a/b/c

Then what will happen with shared mount propagation on / is that
when /dev is mounted to /buildroot/dev, it will be propagated back
to /my/rootfs/path/dev, and so as well to /buildroot/a/b/c/dev. Then,
when /buildroot/a/b/c/dev is unmounted during teardown, /buildroot/dev
will also be unmounted, causing mayhem during cleanup.

Let's stick to slave propagation so the behavior is actually sane.
The only reason we were doing shared is because nspawn was doing it and
the only reason nspawn does it is because some bit of systemd's service
namespacing happens to depend on it.

With shared mount propagation,
Signed-off-by: Daan De Meyer <daan@amutable.com>
mkosi/sandbox.py