Proxmox Kernel 6.14 Is Out of Support and Homelab Admins Feel It

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. For users pinned to 6.14 because their hardware stack behaves there, it felt less like housekeeping and more like a shove.

Updating is only part of the problem

On paper, "move to a supported kernel" sounds reasonable. In practice, homelab systems are a long way from 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. Details like that make 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 started a second clock: 6.17 is planned to start sunsetting at the beginning of July, shifting toward best-effort updates, so 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. People aren't refusing change because they're lazy. A lot of them are weighing running unsupported code against 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. You don't shrug off an incident like that. Once storage gets involved, every kernel upgrade starts feeling like a hostage negotiation. Sure, you have backups, but you also remember the exact sound your stomach made the last time the pool went sideways.

There were counterpoints. 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, though 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 aren't corporate infrastructure, yet 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 make NVIDIA any 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. Proxmox doesn't reach into your system and rip the kernel out just because it's unsupported. Debian may offer to autoremove kernels it thinks are no longer needed, though, so users need to actually read apt output instead of hammering yes like it's a cookie banner. There was also a warning that if you remove 6.14 now, you may not be able to reinstall it later once it disappears from repositories.

That's the hidden 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. 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, and 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 sits between "everyone should jump to 7.0 today" and "never upgrade a working system": 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 ordinary maintenance.

Staying frozen forever isn't a plan, either. 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, which is 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.