umount /run from the chroot fails if new mounts have been added under it

Created by: amcinnes

Using arch-install-scripts 24-2.

To reproduce the issue

mkdir newroot
pacstrap newroot base

# then in another terminal while pacstrap is running:
mkdir /run/foo
mount tmp /run/foo -t tmpfs

Actual behaviour

Before pacstrap finishes I see umount: /home/angus/newroot/run: target is busy., and newroot/run stays mounted, with the tmpfs at newroot/run/foo mounted under it.

Expected behaviour

Everything that pacstrap mounts should be successfully unmounted when pacstrap finishes.

More information

This comment seems to relate to the same issue.

On a systemd system, the root directory and mount points under it (including /run) get the "shared" mount propagation mode by default. There's some explanation in the Linux kernel docs about what "shared" means. Basically it means that when we bind-mount /run into the chroot, subsequent mount events under /run will get replicated into the chroot. Then we can't cleanly unmount the chroot's /run without first unmounting whatever has been mounted under it.

I don't think this is the behaviour we want. The chroot has no real need to access other filesystems mounted beneath /run on the host.

Adding --make-private to the bind mount command should fix this, by preventing the mount events from the host's /run being replicated into the chroot.

Making /run a tmpfs rather than a bind-mount seems like a cleaner option, unless there's some good reason to keep the bind mount. (The original reason was to support lvmetad which is apparently no longer used.)