On Fri, Sep 01, 2023 at 11:13:11PM +0000, Mathias Gibbens wrote: > Control: block 1038315 by -1 > Control: block 1042880 by -1 > > I don't think we have a good understanding of the root cause of this > issue. Initially we thought this was a known upstream issue with all- > but very recent versions of apparmor and a corresponding lxc profile > fix [0]. However, it appears this is a different issue that somehow > depends on the interaction of bookworm's versions of the kernel, > apparmor, and/or lxc. > > A minimal reproducer is to install bookworm and create a container > with a systemd service using a hardening option like > PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the > service will fail. But, grab a kernel from testing (6.4.11-1) and then > things work -- with no other changes required. I tried the "oldest" > kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the > service works properly with that version as well. So, something changed > in the kernel (either upstream or in Debian's packaging) between 6.1 > and 6.3 that "unbreaks" services within lxc containers. > > Given that simply installing a newer kernel fixes things, I am > hesitant to start making changes to lxc until we actually understand > what's changed when running the newer kernel and how it's affecting > lxc's behavior.
Thanks for the investigation. This led to think of something that would work around this issue, but maybe has bigger consequences. I'm wondering whether we should, as a policy, run backports kernels on the ci.debian.net workers. Given the most important use case is testing testing¹, having a kernel that is closest to the one in testing might make sense. ¹ pun intended Of course, this does not prevents having QEMU workers, and I want to provide that at some point. But since we won't be able to have QEMU for all architectures, anyway, I still think running backports kernels in the lxc workers might be a valid strategy.
signature.asc
Description: PGP signature
