Package: systemd
Version: 254.1-2
since systemd 253 was merged into Sid/unstable and Trixie/testing,
systemd-nspawn fails to boot Sid and Trixie containers with foreign
architectures via qemu-user-static and binfmt:
-------
Spawning container rootfs on /root/rootfs.
Press Ctrl-] three times within 1s to kill container.
systemd 254.1-2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR
+IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2
-PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD
-BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization systemd-nspawn.
Detected architecture arm64.
Welcome to Debian GNU/Linux trixie/sid!
Hostname set to <VM-Trixie>.
Failed to fork off sandboxing environment for executing generators:
Invalid argument
[!!!!!!] Failed to start up manager.
Exiting PID 1...
Container rootfs failed with error code 255.
-------
I am not sure whether this has to be addressed in systemd,
systemd-container or qemu-user-static, but I am reporting it here as the
issue appeared with systemd 253 (container end) and it fails the same
way with various systemd-nspawn and qemu-user-static versions from
Debian Bullseye, Bookworm, Trixie, Sid as well as Ubuntu Jammy.
Here is how to replicate on any Debian or Ubuntu host:
-------
sudo apt -y install debootstrap dbus systemd-container qemu-user-static
binfmt-support
sudo systemctl restart systemd-binfmt
debootstrap --arch=arm64 --variant=minbase --include=systemd-sysv trixie
./rootfs
systemd-nspawn -bD rootfs
-------
The same works well when doing the same with the bookworm suite (systemd
252) or when booting a trixie or sid system with natively supported
architecture, hence without QEMU.
The same error has been reported here:
https://github.com/systemd/systemd/issues/26474
A fix was merged with systemd 254, but it does not work for this case.
Also, the reported case seems to require CAP_SYS_ADMIN, while
systemd-nspawn passes this capability anyway, and adding
"--capability=CAP_SYS_ADMIN" hence has no effect either.
Does someone have an idea what the reason for this is? Shall this better
be reported upstream, or does it need to be fixed in QEMU?
Best regards,
Micha
