Proxmox 9.1 Upgrade Reports: Kernel, Network, and GPU Issues

Proxmox 9.1 dropped recently with a lot of anticipation from the virtualization and homelab community, and the upgrade reports since then include kernel panics, network card crashes and GPU trouble. New features, kernel updates, and performance optimizations tend to get the crowd excited until something breaks, and that's exactly what happened to one unlucky user just a day after updating: a hard crash, an obscure netdev watchdog error, and no clues in the logs. Welcome to the wild west of open-source upgrades.

It wasn't a one-off story, either. Dig a little deeper and you'll see multiple users reporting instability after moving to 9.1, ranging from mysterious crashes and network card meltdowns to GPU-related failures that bring down entire systems. The sections below walk through the fallout from the 9.1 upgrade and what it means for Proxmox users both at home and in production.

A crash with no trace

The original post came from a user who upgraded to Proxmox 9.1, only to have their system crash the very next day. The logs were empty. The only real clue was a snapshot from the console showing a netdev watchdog issue tied to a Mellanox ConnectX-3 Pro card. They rolled back to the previous kernel and paused hopefully, but the uncertainty lingered. Was it the kernel, the network driver, or a fluke?

It turns out others are seeing similar instability, and some are already jumping ship.

You're not alone: a pattern of failures

Another user chimed in with a sobering comment: same issue, different scale. On a production system with 20 nodes and a petabyte of NVMe storage, the same netdev crash reared its head. Their solution was to nuke the upgrade and go back to 8.4. "I'll wait another month or two," they said, which sounds more like damage control than confidence.

Yet another user pointed to a potential culprit: frigate_capture, a GPU-based component for video processing. Their theory was that a GPU crash took out the CPU, which in turn sent the NIC spiraling. When hardware acceleration is in the mix, things get spicy fast, especially if you're passing through an iGPU like the Intel 8600 series.

iGPU, LXC, and crashes, oh my

The original poster revealed they were using an iGPU with Frigate, a popular NVR platform. Initially it was tied to an LXC container with Docker inside, a setup that works but often walks the fine line between elegant and cursed.

Eventually, after multiple redeployments (ten, to be exact), they moved Frigate into an unprivileged OCI container. Things have been more stable since then, but the damage was done: kernel crashes, sudden reboots, and hours of recovery and troubleshooting. This is the sort of friction that turns enthusiasts into skeptics.

One commenter's take was brutally honest: "Not ready for prime-time… This 9 won't even run as a sandbox. Epic fail."

Digging into the kernel side

Several users have already found a workaround in rolling back to the latest 6.14 kernel. One user reported that after reverting, things returned to normal. Their crash journey started with TPM issues, involved Tailscale weirdness, and ended in a boot loop they didn't catch in time, all from a point upgrade. That's the kind of hidden landmine that makes sysadmins question every "update now" button.

Mellanox NICs aren't the only ones having issues either. Others flagged problems with Intel NICs, offloading bugs, and BIOS compatibility quirks. A helpful link to a NIC offloading fix script made the rounds, but that's more of a patch than a solution.

What this means for Proxmox users

A few lessons come out of all this.

Don't upgrade blindly, especially with point releases. Test in a sandbox first. If you're running Frigate, GPU passthrough, or custom LXC setups, you're at higher risk.

Keep a rollback plan ready. Whether that means reverting to an earlier kernel or snapshotting your nodes before the jump, prepare for the worst.

Watch out for GPU configs. Frigate is fantastic, but it's also finicky when you're doing hardware acceleration in containers, so make sure you're isolating those workloads cleanly.

Check your BIOS and firmware. An outdated BIOS might be fine on older Proxmox versions but can trigger unpredictable behavior on newer kernels.

Separate config and data volumes. This one was a lifesaver for the OP: if you can redeploy your services by just reattaching volumes, recovery is exponentially easier.

Should you avoid 9.1 altogether?

Not necessarily. Some users have reported clean upgrades and stable performance. If you're running a homelab with edge-case configurations, or worse, you're in production, tread carefully. Early adopters are the testers whether they like it or not.

The golden rule: if your system isn't broken, don't rush to fix it with a shiny update, especially when the stability of your entire virtual infrastructure hangs in the balance.

What could Proxmox do better?

A few things stand out from this community incident. Kernel update notes could be more transparent, since users were caught off guard by behavior changes that weren't clearly documented. Regression testing should use real-world configs, because LXC with Docker, hardware-accelerated Frigate, and Mellanox cards aren't niche anymore. And more granular rollback options would be a massive help, making it easier to revert entire node environments as well as kernels.

Final thoughts

Proxmox is one of the most powerful and flexible open-source hypervisors out there. Power comes with complexity, though, and complexity brings risk. The 9.1 upgrade brought new features along with kernel panics, NIC crashes, and a wave of uncertainty. Until these issues are ironed out, the safe bet is to either wait or isolate your upgrade to a non-critical node. Upgrades are exciting, but in the world of virtualization, stability is king.