Stuck Waiting for Proxmox 9.2: Chasing Newer Kernels for ROCm

The breaking point: when your kernel blocks your curiosity

Some frustration only shows up when you push a setup past what it was built for. Here it was nothing outrageous: ROCm, some LLM workloads, seeing what the hardware can do. Then came a wall: no crash and no misconfiguration, just a kernel slightly too old.

That's the tension at the center of this whole situation. The user isn't chasing bleeding-edge chaos, just a kernel that fixes a couple of upstream issues, and the path forward is unclear. "I don't see a path to upgrade without waiting for 9.2," they admit, and nothing says 9.2 is close.

The reality check: "Proxmox doesn't move at your speed"

One of the most grounded responses cuts straight through the confusion: Proxmox follows Ubuntu kernels. That explains everything and makes it worse, because the delay sits in the upstream chain rather than in Proxmox itself.

You're waiting on layers to align: Ubuntu's kernel schedule, Proxmox's integration, then the release that packages it. It works like a pipeline, and there's no switch to flip. Another commenter added that to predict what's coming, you should watch Ubuntu's roadmap instead of Proxmox announcements. It's logical and structured, and painfully slow.

The hackers: "Just run a new kernel and deal with it"

Not everyone waits. Someone always shrugs: "Just install a new kernel and see if it works." It's half advice, half dare.

That's homelab freedom: nothing is production, so you can break things and roll back. But outside the supported stack you're on your own. Debugging gets harder, updates get messier, and a predictable Proxmox environment drifts into something fragile. For some, waiting still feels worse than tinkering.

The workaround crowd: "If the host won't do it, use a VM"

The pragmatic move is to stop fighting the host kernel. Spin up a VM, pass through the GPU, and run whatever distro you want, whether Fedora, Arch, or anything else with the kernel you need.

It isn't free. GPU passthrough has its own headaches; one user would "love" to switch fully but balked at iGPU passthrough complexity for their workloads, and that friction can defeat the point. Still, Proxmox stays the stable hypervisor while cutting-edge kernels run where they matter.

The confusion layer: Debian, Ubuntu, and what Proxmox really is

Part of this is identity confusion. Proxmox is Debian-based, but the kernel story complicates it. As one surprised commenter put it: "I thought proxmox was Debian based… but it uses a modified Ubuntu kernel."

You expect Debian timelines, but you're tied to Ubuntu's kernel cadence, which changes how you plan an upgrade, troubleshoot compatibility, and set expectations.

The bigger picture: more than a version number

The relatable part is being out of sync: the hardware is ready, upstream has the fix, and the platform is one step behind.

You can wait and stay clean, hack forward and accept the risk, or bolt on workarounds that trade complexity for progress. None of it feels perfect.

In the end, Proxmox 9.2 is just the current example of the standing negotiation between stability and curiosity, and if you're running LLM workloads in a homelab, you know which side you lean toward.