Bug#1050256: autopkgtest fails on debci

[Antonio Terceiro]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230902/f270cb5e/attachment.sig>