Proxmox Kernel 6.14 Just Got Cut Loose, and Homelab Admins Are Feeling the Floor Move

# Proxmox Kernel 6.14 Just Got Cut Loose, and Homelab Admins Are Feeling the Floor Move Kernel news usually lands like dry toast: necessary, technical, and easy to ignore until something breaks. This one didn’t. Proxmox’s 6.14-based kernel series is now out of support, and the announcement hit a very specific nerve in the community. The official message was plain enough: 6.14 had already lived longer than planned, the churn of problematic issues was getting too high, and supported paths now mean 6.8 for Proxmox VE 8, 6.17 for Proxmox VE 9, and 7.0 as the next default for VE 9. But for users pinned to 6.14 because their hardware stack behaves there, this wasn’t housekeeping. It was a shove. ## The Problem Isn’t Just Updating On paper, “move to a supported kernel” sounds reasonable. In practice, homelab systems aren’t clean little diagrams. They’re full of passed-through controllers, aging GPUs, DKMS drivers, ZFS pools, and random hardware combinations that worked only after three weekends of swearing. One user said they had pinned back to 6.8 after DMAR failures on 6.17.9. Another had been stuck on 6.14 for ages because of NVIDIA drivers and container passthrough. That’s the kind of detail that makes a kernel sunset feel less like a routine upgrade and more like someone cutting the rope bridge while people are still crossing it. The announcement also came with a second clock ticking: 6.17 is planned to start sunsetting at the beginning of July, shifting toward best-effort updates. That means the “safe middle” doesn’t feel very permanent either. Kernel 7.0 is the future path, but future paths are where weird I/O issues, driver build failures, and passthrough edge cases love to hide. So people aren’t refusing change because they’re lazy. A lot of them are doing the math between running unsupported code and detonating a working machine. ## DMAR, Passthrough, and the Horror of Almost-Stable Systems The sharpest anxiety in the thread came from passthrough users. One person linked a DMAR regression involving Alder Lake hardware and asked whether the bugs had been resolved. They had passed through SATA and NVMe devices with full PCI passthrough, then faced ZFS corruption after a scrub and had to rebuild the array. That’s not the kind of incident you shrug off. Once storage gets involved, every kernel upgrade starts feeling like a hostage negotiation. Sure, you have backups. You also remember the exact sound your stomach made the last time the pool went sideways. There were counterpoints, though. Another user with a Supermicro board and an Intel i9-14900K said they were passing through a built-in SATA controller to TrueNAS in a VM and hadn’t seen those DMAR messages while staying current on kernels. Someone else suggested trying `intel_iommu=sp_off`, and another said that option had helped with similar 10G NIC passthrough issues. That’s the strange comfort of these threads: nobody has one clean answer, but the pile of hardware stories becomes its own troubleshooting map. “Works for me” isn’t proof. But it’s still a useful flashlight. ## NVIDIA Users Are Still in the Basement Then there’s NVIDIA, because there’s always NVIDIA. A user with a 1000-series GPU said they still couldn’t build the NVIDIA module on kernel 6.17. Another had a GTX 1070 used for encoding and wanted to know whether the driver situation was safe before touching newer kernels. Someone did offer a lifeline: they got NVIDIA 550 drivers to build and work with kernel 7.0 through a GitHub repo. The reply was grateful, but cautious. A custom script may get the job done, but plenty of admins would rather not glue their media stack together with something that feels one repo away from abandonment. That tension is familiar. The open-source world is full of brave workarounds, and many of them are genuinely useful. But production-adjacent homelabs sit in a weird middle ground. They’re not corporate infrastructure, but they still run family photos, Plex boxes, home automation, backups, remote work tools, and sometimes actual business services. “Just try the patched driver” sounds different when the machine is your only server. Kernel 6.14 going unsupported doesn’t magically make NVIDIA easier. It just makes staying put feel worse. ## Unsupported Doesn’t Mean Deleted, But It Does Mean Lonely One practical question cut through the panic: does Proxmox automatically uninstall unsupported kernels that aren’t in use? The answer from the thread was no, not directly. Unsupported doesn’t mean Proxmox reaches into your system and rips the kernel out. But Debian may offer to autoremove kernels it thinks are no longer needed, so users need to actually read apt output instead of hammering yes like it’s a cookie banner. There was also a warning: if you remove 6.14 now, you may not be able to reinstall it later once it disappears from repositories. That’s the quiet danger of kernel pinning. It feels like stability until it becomes a dead end. Keeping the old kernel around can buy time, especially if a newer one breaks GPU drivers or passthrough. But once security updates stop and packages move on, that pinned setup starts turning into an island. One commenter said their nodes weren’t exposed outside the network and firewall rules limited access, so they had accepted the risk for now. That’s honest. It’s also the kind of sentence every admin says right before adding one more item to the mental debt pile. ## The Upgrade Path Is a Trust Exercise The strongest opinion here isn’t “everyone should jump to 7.0 today” or “never upgrade a working system.” It’s that kernel transitions are trust exercises, and Proxmox users have very good memories. If a kernel breaks passthrough, corrupts storage, or wrecks a DKMS build, people don’t forget just because the next announcement says the older branch is done. They want clear notes, known-good hardware reports, rollback options, and enough community chatter to know whether they’re walking into a minefield. That’s not paranoia. That’s maintenance. Still, staying frozen forever isn’t a plan. The reasonable path is boring but real: keep backups fresh, confirm you still have a bootable older kernel, test the new kernel before removing anything, watch apt like a hawk, and read hardware-specific reports before trusting your weird stack to the future. Kernel 6.14’s exit is painful because it forces a decision users were already delaying. And that’s why the thread feels so tense. Nobody is mad that unsupported software eventually dies. They’re mad because, for some systems, it was the last version that behaved.