Incus container has stopped working after system update? Mounting cpuinfo failed

,

Hi all,

I’m having some trouble starting my incus containers on Fedora 42. It seems that a recent update may have caused some trouble.

Checking the log for the container (and enabling trace logging) shows the following error:

lxc gaming 20250926063301.420 DEBUG utils - ../src/lxc/utils.c:run_buffer:560 - Script exec /usr/share/lxcfs/lxc.mount.hook produced output: mount: /usr/lib64/lxc/rootfs/proc/cpuinfo: bind /var/lib/lxcfs/proc/cpuinfo failed.
dmesg(1) may have more information after failed mount system call.

lxc gaming 20250926063301.420 ERROR utils - ../src/lxc/utils.c:run_buffer:571 - Script exited with status 32

No configuration changes were made on my end prior to the incus container failing to start; there was an update and the container did not start on the second boot.

Can you show ls -lh /var/lib/lxcfs?

total 0
dr-xr-xr-x. 2 root root 0 Sep 26 10:58 proc
dr-xr-xr-x. 2 root root 0 Sep 26 10:58 sys

Okay and does cat /var/lib/lxcfs/proc/cpuinfo work?

No, with both a user account under incus-admin and under root, I get permission denied. In journalctl, I get the error

lxcfs[2225]: ../src/proc_fuse.c: 153: proc_getattr: Due to restricted personality access policy, reading proc files from containers is not permitted

I did notice that SELinux was denying lxcfs’s ptraces; I disabled the deny_ptrace rule, but it also hasn’t changed anything. The error remains the same.

Check /proc/sys/kernel/yama/ptrace_scope, a value of 3 is likely to cause this kind of situation. My system here is running with a value of 1.

Currently running at a value of 0

Out of curiosity, I also tried downgrading kernel to 6.16.5 (pre-update), but this did not change anything.

Figured the problem out. It turns out that incus/lxc does not automatically react to an SELinux policy change. I disabled deny_ptrace, but did not restart incus/lxcfs systemd services.

Thanks for the help!

1 Like