Yeah, that boot-time warning is annoying as hell, especially when you're not even using RDMA. Let's fix it.
The Fix
The fastest way to silence it is to tell the kernel to not enable the rdma cgroup controller at all. Edit your bootloader config and add cgroup_no_v1=rdma to the kernel command line.
On most systems with GRUB, edit /etc/default/grub and modify the GRUB_CMDLINE_LINUX_DEFAULT line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cgroup_no_v1=rdma"Then regenerate the GRUB config and reboot:
sudo grub-mkconfig -o /boot/grub/grub.cfgIf you're on a systemd-boot (common on Arch or Fedora), edit the appropriate entry in /boot/loader/entries/ and append cgroup_no_v1=rdma to the options line.
After reboot, the error should be gone. But there's a second angle: systemd itself tries to mount cgroup2 with all controllers it knows about, including rdma. You can stop that by editing /etc/systemd/system.conf and uncommenting or adding:
DefaultCPUAccounting=no
DefaultBlockIOAccounting=no
DefaultMemoryAccounting=no
DefaultTasksAccounting=noWait, that's not it. The relevant setting is DefaultControllers=, but it's not in the default file. You can add:
DefaultControllers=cpu cpuacct cpuset io memory pidsThat tells systemd to only enable those controllers for new units. But honestly, the kernel cmdline fix is cleaner and works across the board.
Why It Worked
What's actually happening here is a mismatch between systemd's expectations and your kernel's capabilities. systemd is built with support for the rdma cgroup controller (added in kernel 4.10, I think), but your kernel either has it disabled in the config or it's a module that didn't load. When systemd tries to mount cgroup2 with the rdma option, the kernel replies with an EINVAL because it doesn't recognize that controller.
Adding cgroup_no_v1=rdma tells the kernel to not even register the rdma controller in the cgroup v1 hierarchy, which also prevents it from being available in v2. Since systemd checks what controllers are available before mounting, it skips rdma, and the error goes away.
The reason this appears on systemd boot specifically is that systemd mounts cgroup2 early in the boot process, before any userspace service that might use rdma is even started. It's a warning, not a fatal error, so the system still boots, but it's a sign that your cgroup setup isn't fully functional. Ignoring it might mean you can't use rdma cgroup limits later if you ever need them.
Less Common Variations
Sometimes the same error shows up for other controllers. I've seen cgroup2: unknown option "cpu" on really old kernels that didn't have the cpu controller in v2 yet. The fix is the same: use cgroup_no_v1=cpu or update your kernel.
Another variation is when the error appears not at boot, but during a container runtime start (Docker, Podman). That happens when the runtime tries to mount cgroup2 with all controllers, and the same mismatch occurs. The kernel cmdline fix still works, but you might also need to configure the runtime to ignore rdma. For Docker, add "exec-opts": ["native.cgroupdriver=systemd"] to /etc/docker/daemon.json – no, that's a different issue. Actually, just ensure the kernel module rdma_cgroup is loaded. Check with:
lsmod | grep rdmaIf it's not loaded, try modprobe rdma_cgroup and see if the error persists. On some kernels, the rdma controller is built as a module and isn't loaded at boot. Loading it manually might make systemd happy, but that's a temporary fix. The kernel cmdline approach is more robust.
Prevention
The real prevention is to align your kernel config with what systemd expects. If you build your own kernel, make sure the cgroup controllers you want are built-in (not modules) – specifically CONFIG_RDMA_CGROUP=y. If you're using a distro kernel, this is a distro packaging issue, and the kernel cmdline fix is your best bet.
Also, keep your systemd and kernel versions in sync. If you update one but not the other, you'll get these kinds of mismatches. Check your distro's forums – this error was common on Ubuntu 20.04 with certain kernel updates. The fix I gave is the one that most people landed on.
One more thing: if you're using a container runtime, make sure it's configured to use the cgroup v2 API and not the legacy v1. The error is a symptom of trying to mount cgroup2 with v1-style options. Setting systemd.unified_cgroup_hierarchy=1 in the kernel cmdline forces full v2, which might also help in some edge cases.
Test after reboot: cat /proc/cmdline to confirm the option is there, and dmesg | grep cgroup to see if any errors remain. If you still see the error, double-check that your bootloader actually applied the change – I've seen GRUB caching issues where you need to run update-grub instead of grub-mkconfig on Ubuntu.
That's it. It's a five-minute fix that saves you from a boot-time annoyance and potential cgroup weirdness later.