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

[Simon McVittie <smcv@xxxxxxxxxxxxx>]

On Sat, 03 Dec 2022 at 23:38:55 +0100, Bernhard Übelacker wrote:
> > No SELinux or Apparmor active
> 
> As far as I see in my test VM with minimal Debian Buster there is no SELinux.
> "aa-status" returns "apparmor module is loaded.", but I did not intentionally
> configure anything to it.

Debian uses AppArmor by default (same as Ubuntu), unless you have
intentionally configured it not to. Debian does not use SELinux by default
(again, same as Ubuntu).

> Yes, it is an test to use on an older Debian Buster with kernel 4.19.260-1
> a quite recent Debian Bookworm/testing system.

For those on this mailing list who might not be familiar with Debian
codenames, 'buster' on the host system is Debian 10, an "old stable"
version released in 2019 and maintained by the Debian LTS team. The
recommended stable Debian system right now is Debian 11 (released in
2021) but some change-averse organizations stay on older releases for
whatever reason.

'bookworm' in the container is a development branch of the distribution:
think of it as an alpha or beta of Debian 12. The Debian 12 stable release
is expected to happen in mid 2023.

> 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?

The way this is usually meant to work when new user-space runs on an old
kernel is that faccessat2 fails with error ENOSYS, and glibc falls back
to emulating it via an older syscall like faccessat. It's OK for this
fallback to occur, as long as the older syscall gives the right result.
If the fallback gives the wrong result, then that would be a glibc issue
(either an imperfect emulation, or a missing/unimplementable feature on
older kernels).

    smcv