jiangcuo
cgroup_disable=memory is forced on Raspberry Pi 5, breaking K3s and container RAM stats
Describe the bug After a fresh installation of PXVIRT on a Raspberry Pi 5, the Proxmox host persistently boots with the cgroup_disable=memory kernel parameter. This prevents memory cgroups from being enabled. As a result, the Proxmox web UI cannot display RAM usage for LXC containers, and more importantly, it's impossible to run container orchestrators like K3s, which fail to start because they cannot access required memory cgroup information.
To Reproduce teps to reproduce the behavior: Install Raspberry Pi OS Lite (64-bit) on a Raspberry Pi 5. Install PXVIRT by following the official documentation (https://docs.pxvirt.lierfang.com/en/installfromdebian.html). After installation and reboot, SSH into the Proxmox host. Run cat /proc/cmdline and observe that cgroup_disable=memory is present. Create a privileged LXC container (e.g., Debian 12). Try to install K3s in the container using curl -sfL https://get.k3s.io | sh -. The K3s service will fail to run and enter a crash-loop, with logs indicating it cannot access system information correctly (e.g., Failed to set sysctl, Found node without any CPU).
Expected behavior The Proxmox host should boot without the cgroup_disable=memory parameter. The kernel command line should have cgroup_enable=memory to allow modern container workloads to function correctly on the Raspberry Pi.
Screenshots The output of /proc/cmdline showing the unwanted parameter:
root@pi5-1:~# cat /proc/cmdline reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave ... The error from K3s service logs inside the LXC container: time="2025-09-09T22:55:39+03:00" level=error msg="Failed to set sysctl: open /proc/sys/net/n> W0909 22:55:39.550152 5136 sysinfo.go:227] Found node without any CPU, nodeDir: /sys/devi>
ENV (please complete the following information): -OS: Raspberry Pi OS Lite (64-bit) based on Debian 12 (Bookworm) -ARCH: arm64
- Version :
proxmox-ve: 8.3.1 (running kernel: 6.12.34+rpt-rpi-v8) pve-manager: 8.4.10 (running version: 8.4.10/01d2d7dd794a93d5) proxmox-kernel-helper: 8.1.0-3 ceph-fuse: 17.2.7-pve3 corosync: 3.1.9-pve1 criu: 3.17.1-2+deb12u2 glusterfs-client: 10.3-5 ifupdown2: 3.2.0-1+pmx11 libjs-extjs: 7.0.0-5 libknet1: 1.28-pve1 libproxmox-acme-perl: 1.5.1 libproxmox-backup-qemu0: 1.4.1 libproxmox-rs-perl: 0.3.5 libpve-access-control: 8.2.2 libpve-apiclient-perl: 3.3.1 libpve-cluster-api-perl: 8.1.2-1 libpve-cluster-perl: 8.1.2-1 libpve-common-perl: 8.3.4 libpve-guest-common-perl: 5.2.2 libpve-http-server-perl: 5.2.2 libpve-network-perl: 0.11.2 libpve-rs-perl: 0.9.4 libpve-storage-perl: 8.3.6-1 libspice-server1: 0.15.2-2 lvm2: 2.03.16-2 lxc-pve: 6.0.0-1 lxcfs: 6.0.0-pve2 novnc-pve: 1.6.0-2 proxmox-backup-client: 3.3.2-2 proxmox-backup-file-restore: 3.3.2-2 proxmox-backup-restore-image: 0.6.1+port3 proxmox-firewall: 0.5.0 proxmox-kernel-helper: 8.1.0-3 proxmox-mail-forward: 0.2.0 proxmox-mini-journalreader: 1.4.0 proxmox-offline-mirror-helper: 0.6.6 proxmox-widget-toolkit: 4.3.13 pve-cluster: 8.1.2-1 pve-container: 5.3.0 pve-docs: 8.4.1 pve-edk2-firmware: 4.2025.02-3 pve-firewall: 5.1.2 pve-firmware: not correctly installed pve-ha-manager: 4.0.7 pve-i18n: 3.4.2 pve-qemu-kvm: 9.2.0-5+port3 pve-xtermjs: 5.5.0-2 qemu-server: 8.4.1 smartmontools: 7.3-pve1 spiceterm: 3.3.0 swtpm: 0.9.0+port vncterm: 1.8.0 zfsutils-linux: 2.3.1-1~bpo12+1~rpt1
Additional context We have exhaustively tried to override this parameter through every known mechanism on a Raspberry Pi, with no success. This includes: Editing /boot/firmware/cmdline.txt Editing /boot/firmware/config.txt Creating /etc/kernel/cmdline and running update-initramfs Inspecting the initramfs image itself Checking the EEPROM configuration with rpi-eeprom-config None of these methods work, which strongly suggests the cgroup_disable=memory parameter is being forcefully injected by a PXVIRT-specific boot script in a non-standard way. This makes the current installation unsuitable for any Kubernetes or advanced container workloads. Removing this parameter is critical.
Hello,
I'm not sure what you're trying to do, but when I used Kubernetes with PXVirt, I created a VM to act as the Master and set up additional VMs for the Workers, and I didn't encounter that problem. As for LXC, I just did what was necessary to resolve the common issue.
