`mkosi boot` ignores `Bind=` nspawn configuration

[DCKcode]

mkosi commit the issue has been seen with

4ed5a8b , 25.3 stable

Used host distribution

Fedora 42

Used target distribution

Fedora 42

Linux kernel version used

6.14.9-300.fc42.x86_64

CPU architectures issue was seen on

x86_64, aarch64

Unexpected behaviour you saw

This is a minimal example version of this discussion which makes me believe there is a bug in mkosi boot.

Reproduction steps

(On Fedora 42)

Create an empty directory with just the file mkosi.nspawn with contents

[Files]
Bind=/runtime/test:/test

Run mkosi boot -a --package=filesystem,systemd,util-linux (to build a minimal bootable nspawn container with autologin) and finally mkosi boot.

Expected result

Based on systemd.nspawn documentation and the mkosi NSpawnSettings documentation, I see a booted container with /test mounted from my host into the container.

Actual result

I see a booted container, but no /test directory is mounted or even present in the container.

Notes

The configuration in mkosi.nspawn is not ignored entirely, which can be confirmed by e.g. adding the ReadOnly=true directive to the [Files] section. It just seems to be ignoring certain other directives in the nspawn configuration.

Used mkosi config

This reproduces on any image that boots into a shell with mkosi boot. A minimal example can be generated by e.g. mkosi boot -a --package=filesystem,systemd,util-linux on Fedora.

mkosi output

N/A

[DCKcode]

By extension, it similarly appears that setting

[Files]
TemporaryFileSystem=/test

is also ignored.

[DaanDeMeyer]

I tried to reproduce this on Arch Linux but failed, it all works as expected for me. Please see if you can reproduce this with git main.

[DCKcode]

Hmm, interesting. I tried reproducing on Arch Linux again just now and the issue is no different when on Fedora or when testing the earlier revision. Here's how I reproduced it:

Created a quick Arch Linux VM with Lima:

limactl create --name=arch template:///archlinux
lima start arch

Then, in the VM:

sudo -s
pacman -Syu
pacman -Sy nano git python-pipx
pipx install git+https://github.com/systemd/mkosi.git
export PATH=$PATH:~/.local/bin
mkosi --version # v26~devel
pacman -Sy (mkosi dependencies | tr '\n' ' ')
mkdir -p /runtime/test
cd /root
nano mkosi.nspawn
mkosi build -a --package=base,util-linux,systemd
mkosi boot

with the contents of mkosi.nspawn set to either

[Files]
Bind=/runtime/test:/test

or

[Files]
TemporaryFileSystem=/test

there's no /test directory in the resulting container. Adding ReadOnly=true does have effect as per the original report.

[DaanDeMeyer]

@DCKcode Your example uses mkosi.spawn but the file is supposed to be named mkosi.nspawn

[DCKcode]

@DaanDeMeyer that's a copying error that I've corrected, sorry about that. As mentioned, setting the ReadOnly= attribute in the configuration file is effective, so that shows the configuration file is being read.

[tapetersen]

I encounter the same issue on Ubuntu 24:04 (with newer systemd and mkosi from OBS, currently reported as 25.3.999+570+gf3a9ea6-0).

In my case it's with BindReadOnly but doesn't change with simple bind.

[Files]
BindReadOnly=/var/run/mysqld

[tapetersen]

Without having been able to find anything conclusively some experimenting with mkosi boot --debug and checking that the generated command seems to work on it's own my guess would be it could reasonably have something todo with the sandboc mkosi sets up to run systemd-nspawn in and that if I understande the code correctly /run would be bind-mounted into the sandbox and therefore needs systemd-nspawn to do a recursive bind-mount.

Pardon my inexperience in the finer details but glancing at what I can see it seems like a plausible cause, maybe related to this systemd/systemd#38505.

[tapetersen]

I've run mkosi with the --debug flag and copied the systemd-nspawn call it outputs to run outside the sandbox (had to remove the parts for /var/tmp and credentials that relied on a tmpdir created by mkosi but I don't think they come into play for this issue) and can confirm that it indeed lets the bind mount be seen in the booted system.

Is there anything else I could help with to easier identify the root of this @DaanDeMeyer . I've not yet tested on a git checkout of latest mkosi branch but will do when I have time. Given I already run what I expect to be quite recent versions (from OBS) I thought there was a good chance they were close enough but I will try later tonight when I have time.

[tapetersen]

Confirmed with latest master

~/Projects/mkosi$ git describe 
v25.3-603-g62765f2d