[systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

Bernhard Übelacker bernhardu at mailbox.org
Mon Dec 5 17:31:53 UTC 2022



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



More information about the systemd-devel mailing list