On Mon, 2023-05-29 at 20:03 +0200, Paul Gevers wrote: > We have three layers here. The bare metal is arm64. It hosts several > arm* QEMU VM. Inside the VM we run the lxc. I put the output of all > three at the bottom. *Maybe* it's relevant that the bare metal still > runs bullseye while the VM's run bookworm. I'll also share the > content for an arm64 host (which is a VM where I don't have access to > the bare metal.)
[snip] > # generating the container and showing inside > debian@ci-worker-armhf-01:~$ sudo lxc-copy -N elbrus > autopkgtest-unstable-armhf && sudo lxc-start elbrus && sudo lxc- > attach elbrus > root@elbrus:/# cat /proc/cpuinfo > root@elbrus:/# ls -al /proc/cpuinfo > -r--r--r-- 1 root root 3878 May 29 17:48 /proc/cpuinfo Yeah, that's definitely not right! I don't currently have an armel/armhf system to test on, but did try using the abel.d.o porterbox. lxcfs requires elevated permissions to start, which I don't have on that box. Some other things we can look at -- are there any errors/warnings in the lxcfs service journal and/or the system's dmesg that is running lxcfs? It might also be useful to start lxcfs with debugging (`-d`) if there's nothing being logged about populating /proc/cpuinfo. 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. Mathias
signature.asc
Description: This is a digitally signed message part
