On Sat, 18 Mar 2023 at 07:17:34 +0100, Paul Gevers wrote: > I ran the [accountsservice autopkgtest] (lxc backend, just > like on ci.d.n) on my own laptop running bookworm and the test hangs > like on the other architectures.
Some potentially interesting data points: I can reproduce this (or something similar) with an a-v-podman container (image built with a-b-podman --init=none) or an a-v-podman --init container (image built with a-b-podman --init=systemd) on a sid kernel. A sid lxc container in a bookworm VM (built with a-b-lxc from bookworm) doesn't currently start up at all for me, so I cannot confirm or deny whether that particular scenario passes or fails this test. I think there's some orthogonal brokenness with a-b-lxc or a-v-lxc, not involving accountsservice. (Wild guess: lxc-templates or a-b-lxc might need updating to account for the /usr merge, or for formerly Essential packages having become non-Essential; or recent sid systemd might need Paride's recent await-boot.sh improvements.) After working around #1072004 with <https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/390>, I *can't* reproduce this for accountsservice 22.08.8-6 from bookworm in a bookworm qemu VM (a-b-qemu + a-v-qemu on sid), or in a bookworm lxc container inside a bookworm qemu VM. I also can't reproduce this for accountsservice 22.08.8-6.1 from sid, in a sid qemu VM. I haven't yet tried lxc inside a non-bookworm VM, or sid's a-b-lxc and a-v-lxc on bookworm. I'm reluctant to run lxc directly on my host system, because unlike typical uses of podman, it's a privileged container framework for which the motto is "containers don't contain". smcv
