RFE: nspawn: allow to disable os-release safety check via env var or so

[rfc1036]

systemd version the issue has been seen with

254.1-3

Used distribution

Debian

Linux kernel version used

6.4.0-2-amd64

CPU architectures issue was seen on

x86_64

Component

systemd-nspawn

Expected behaviour you didn't see

I think that systemd-nspawn should be able to start containers which have an empty and bind-mounted /usr directory.

Unexpected behaviour you saw

systemd-nspawn fails to start containers with a bind-mounted /usr if /etc is empty or if /etc/os-release is the usual symlink to the file in /usr.

Steps to reproduce the problem

Initialization:

mkdir /var/lib/machines/empty/
ln -s usr/bin usr/sbin usr/lib usr/lib64 /var/lib/machines/empty/

The container fails to start:

systemd-nspawn --private-network -b -D /var/lib/machines/empty/ --bind-ro=/usr

Unless I create a bogus os-release file:

mkdir /var/lib/machines/empty/etc/
echo ID=hack > /var/lib/machines/empty/etc/os-release
systemd-nspawn --private-network -b -D /var/lib/machines/empty/ --bind-ro=/usr

Additional program output to the terminal or log subsystem illustrating the issue

root@bongo:~# systemd-nspawn --private-network --network-veth -b -D /var/lib/machines/empty/ --bind-ro=/usr
Directory /var/lib/machines/empty doesn't look like an OS root directory (os-release file is missing). Refusing.
[Exit 1]
root@bongo:~#

[poettering]

I am not sure I follow? Why not just populate /usr/lib/os-release with a valid file?

[rfc1036]

There is a valid file there after the container is started, but while it is being started /var/lib/machines/$NAME/usr/ is empty because /usr/ will be bind-mounted from somewhere else.

[poettering]

This setup is kinda weird, but I guess we should support it, at least via some env var you can set that relaxes the os-release check.

Happy to take a patch for that!