Am 03.12.22 um 23:38 schrieb Bernhard Übelacker:
I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set follow-fork-mode
child'
and gdb from inside the container via plain chroot seems working well.
So it looks like the failing "syscall_0x1b7" from strace is "faccessat2"
[2].
And it seems "faccessat2" got added just in kernel 5.8 [3],
therefore it might fail with the kernel 4.19.
So I fear this needs a newer kernel, and/or this is more a glibc issue
then?
Hello,
just a few short additions.
I was looking further into this issue, and found disabling apparmor
by booting the host with "apparmor=0" did not improve the situation.
Then I found following entry in the systemd debian package changelog [1][2]:
* seccomp: allow turning off of seccomp filtering via env var.
Since glibc 2.33 faccessat() is implemented via faccessat2(), which
is breaking running containers that use such a version of glibc under
systemd-nspawn in Buster.
Turning off seccomp filtering via the SYSTEMD_SECCOMP env var makes it
possible to run such new containers. (Closes: #984573)
This fits perfectly the situation and the container starts
successfully with this workaround:
SYSTEMD_SECCOMP=0 systemd-nspawn
--directory=/var/lib/machines/test-bookworm --boot
Kind regards,
Bernhard
[1]
https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_241-7~deb10u8_changelog
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984573
