From terceiro at debian.org Thu Oct 1 20:52:20 2026 From: terceiro at debian.org (Antonio Terceiro) Date: Thu, 1 Oct 2026 16:52:20 -0300 Subject: [pkg-lxc-devel] Bug#1144803: lxc: autopkgtest fails under incus-lxc: several test failures In-Reply-To: <40d4f4aa7a40d2e5e0ad07cd752dc556b5388ef7.camel@debian.org> References: <40d4f4aa7a40d2e5e0ad07cd752dc556b5388ef7.camel@debian.org> Message-ID: On Sat, Sep 26, 2026 at 05:45:40PM +0000, Mathias Gibbens wrote: > control: tags -1 + pending > > On Tue, 2026-08-18 at 20:49 -0300, Antonio Terceiro wrote: > > Debian CI is switching away from lxc containers in favor of incus Containers. > > This is motivated by security concerns from us; incus is based on lxc, but > > orchestrates containers substantially different: containers are not privileged > > (so root in the container is not uid 0 outside of it, and incus imposes a > > stricter isolation from the host system. > > > > lxc passes its tests under lxc, but fails under incus. This is a bit ironic. :-) > > Yeah, that's funny, but caused by exactly what makes Incus a better > CI environment -- unprivileged containers by default. :) I've added a > commit[0] for lxc's packaging that's similar to what Leah (CC'ed) has > proposed coming from Ubuntu's packaging of lxc. > > I think there will be a new lxc release (7.0.1) in the near future, > so I'll plan to include this change in the next release of Debian's > packaging of lxc. Thanks. > > If you decide to add the `isolation-machine` restriction to get this package > > tested under qemu, please mention that explicitly when closing this bug (it's > > fine to do that only in the package changelog entry that closes the bug) so > > that we can configure your package for qemu on ci.debian.net. > > Running the autopkgtests within a VM will give full test coverage, so > in an ideal world that would be preferable to running a subset of the > tests in containers. If I remember correctly, in the past QEMU runners > in the CI infrastructure were limited to just amd64 (and maybe arm64?), > is that still true? Or are QEMU runners available for all architectures > that run CI tests? If not, I'd choose to keep running lxc's subset of > tests within containers on all CI architectures versus running all of > lxc's tests on just amd64 and/or arm64 within VMs. We have qemu only for amd64. It will fallback to whatever is available on the other architectures, so any tests where you declare `Restrictions: isolation-machine` will be skipped on non-qemu, while the ones that don't will still run. You can also not declare anything, and change the tests themselves to detect whether they are being run in a VM or not and have them do the right thing. Should I switch lxc to run under qemu? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: