Mathias Gibbens <gib...@debian.org> wrote on 06/06/2023 at 04:06:14+0200:
> [[PGP Signed Part:No public key for 29EEE2D6ECF442F9 created at > 2023-06-06T04:06:14+0200 using RSA]] > On Thu, 2023-06-01 at 18:58 +0200, Pierre-Elliott Bécue wrote: >> > I should have time this weekend when I can spin up a qemu vm to >> > test in, if we're not able to get a root cause identified before >> > then. > > I did try to reproduce the issue over the weekend with qemu. Using > qemu-user-static and systemd-nspawn was insufficient due to lxcfs > needing proper access to the fuse kernel api. After trying and failing > to bootstrap an armhf instance by hand, I grabbed a raspberry pi 2 > bookworm image from raspi.d.n, and got it running under qemu-system- > arm. Within that environment, lxcfs appeared to work correctly > (/var/lib/lxcfs/proc/cpuinfo was correct, no obvious errors or warnings > noticed). I didn't spin up a full lxc container instance within that > environment. > >> I can probably grant you privileges on abel as soon as I get an ack >> from my fellow DSA mates. > > If it's possible to get temporary permissions on abel, that would be > useful. > > One other thing to double check on ci-worker-armhf-01 would be the > contents of /var/lib/lxcfs/proc/cpuinfo, so we can see what lxcfs is > doing from the host side. Unfortunately my teammates have some concerns and I don't have the time for the debate now. What I can do is run any required tests myself. Could you tell me what you wanted to try so that I can try it out for you and report back with the results? -- PEB
