How migrating from Linux Mint to headless Proxmox accidentally solved a problem I thought was unsolvable<\/em><\/p>\n\n\n\n If you run Frigate NVR on older Intel hardware, you may have noticed that “working” and “stable” are two very different things. This is the story of how an HP EliteDesk Mini G3 with an i5-6500 (Skylake) went from crashing multiple times a day to running for days without incident \u2014 and why I can’t fully explain why.<\/p>\n\n\n\n The goal was simple: a dedicated, low-power NVR box for Frigate with five cameras, hardware-accelerated decoding via Intel VAAPI, and the OpenVINO detector for object detection. The hardware was an HP EliteDesk Mini G3 \u2014 compact, fanless, sips power. The original OS was Linux Mint, kept around from a previous life as a desktop machine.<\/p>\n\n\n\n Frigate ran in a Docker container directly on Linux Mint \u2014 no virtualization layer, just Docker on a desktop OS. VAAPI worked. Detection worked. The preview timeline ribbon worked. Everything looked fine \u2014 until the crashes started.<\/p>\n\n\n\n The Skylake iGPU (Intel HD 530) has a known relationship with the Under sustained VAAPI decode load \u2014 which is exactly what Frigate does, continuously, for every camera stream \u2014 the After a hang, the driver attempts a GPU reset. Sometimes it recovers. Often it doesn’t \u2014 and when it doesn’t, Frigate loses its decoder, Docker becomes unresponsive, and eventually the entire node needs a reboot.<\/p>\n\n\n\n At its worst, the box was crashing every few hours. Uptime above 12 hours was rare.<\/p>\n\n\n\n With the crashes confirmed as an i915 problem under sustained VAAPI load, the options on Linux Mint were limited.<\/p>\n\n\n\n Reducing detection frames:<\/strong> Lowering the number of frames Frigate passed to the GPU for detection (down to 2) helped reduce the frequency of hangs. It didn’t eliminate them, but it bought more time between crashes. This setting was carried over to the Proxmox setup and is still in place today. Not a fix \u2014 just turning down the pressure on a leaking pipe.<\/p>\n\n\n\n The HA watchdog:<\/strong> The real mitigation was a Home Assistant automation. Since the entire node would become unresponsive \u2014 not just Frigate \u2014 I set up a ping monitor in Home Assistant that continuously checked whether the box was reachable. When it stopped responding, an automation would cut power via a smart plug and turn it back on. The box would reboot, Frigate would come back up, and the cameras would be live again within a few minutes.<\/p>\n\n\n\n But here’s the part that made this setup genuinely frustrating: opening the Frigate web UI to actually watch the cameras would trigger a crash after a few minutes. When you open the live view, Frigate starts encoding additional frames to serve the stream \u2014 that extra GPU encode load was enough to push the i915 driver over the edge. The system that was supposed to let me monitor my home would reliably crash within minutes of me trying to use it for exactly that purpose. The watchdog would kick in, the box would reboot, and I’d be back to square one.<\/p>\n\n\n\n That’s not a workaround. That’s a system that works only when nobody is looking at it.<\/p>\n\n\n\n The original setup was Linux Mint installed on an SSD, with Frigate recording to an external USB hard drive. It worked, but it was a general-purpose desktop OS running a 24\/7 surveillance workload \u2014 with a display manager, compositor, and GUI login screen all sitting idle, consuming resources and sharing the The real reason to move to Proxmox was operational: cluster membership for centralized management and backups. The plan was always to wipe Linux Mint and install headless Proxmox regardless of whether it helped Frigate. The stability improvement was not the goal \u2014 it was a side effect.<\/p>\n\n\n\n After the migration:<\/p>\n\n\n\n Uptime went from under 12 hours to multiple days. Then a week. As far as I can tell, the watchdog hasn’t fired once since.<\/p>\n\n\n\n Here’s where I have to be honest: I can’t definitively explain the improvement. A few theories:<\/p>\n\n\n\n The compositor theory.<\/strong> Linux Mint’s desktop compositor (Muffin) was actively using the iGPU for display rendering, even with no monitor connected. Removing it likely gave the There’s also circumstantial evidence that supports it: while Frigate was running on Linux Mint, the desktop itself became basically unusable \u2014 sluggish, unstable, barely responsive. The box was supposed to be headless at that point anyway, but the fact that the whole desktop environment degraded under Frigate’s load suggests the GPU was genuinely being overworked \u2014 pulled in two directions at once.<\/p>\n\n\n\n The kernel theory.<\/strong> Linux Mint ships a recent upstream kernel. Proxmox ships a more conservatively patched kernel tuned for server workloads. It’s possible the Proxmox kernel has better i915 scheduling or fewer regressions on Skylake specifically.<\/p>\n\n\n\n The “just less stuff running” theory.<\/strong> A minimal headless Proxmox install has dramatically less userspace touching the GPU than a full desktop OS. Fewer background processes, no screensaver, no hardware acceleration in a browser nobody’s using.<\/p>\n\n\n\n The “it was always going to be fine, I just didn’t know” theory.<\/strong> Maybe the instability was already improving and the timing was coincidental.<\/p>\n\n\n\n I genuinely don’t know which of these is the real answer \u2014 or whether it’s all of them together.<\/p>\n\n\n\n In hindsight, maybe I should have known better than to provision Frigate on a desktop OS in the first place. And maybe I should have anticipated that something as GPU-heavy as continuous VAAPI decode across five camera streams wasn’t a great fit for hardware that was already doing double duty as a daily driver. But I love Linux Mint \u2014 it’s still my daily driver on my main machine \u2014 and at the time it was the path of least resistance. Sometimes you learn the hard way.<\/p>\n\n\n\n The box has been running stable since the migration. The HA watchdog is still configured because there’s no reason to remove it, but as far as I can tell it hasn’t fired once since the migration.<\/p>\n\n\n\n Frigate performs exactly as it did before: VAAPI hardware decode for all five streams, OpenVINO for object detection, the preview timeline ribbon intact. The user experience is unchanged. The operational experience is dramatically better.<\/p>\n\n\n\n If you’ve run Frigate (or any VAAPI workload) on Skylake hardware and have dug deeper into the i915 instability, I’d genuinely like to hear what you found. Specifically:<\/p>\n\n\n\n The crash is gone for now. But “gone” and “understood” aren’t the same thing \u2014 and the next person to hit this problem deserves a better answer than “try running it headless and see what happens.”<\/p>\n\n\n\n Hardware: HP EliteDesk Mini G3, Intel i5-6500 (Skylake), Intel HD 530. Running Proxmox VE 9 with a privileged Debian 13 LXC, Frigate via Docker, VAAPI via How migrating from Linux Mint to headless Proxmox accidentally solved a problem I thought was unsolvable If you run Frigate NVR on older Intel hardware, you may have noticed that “working” and “stable” are two very different things. This is the story of how an HP EliteDesk Mini G3 with an i5-6500 (Skylake) went from … Continue reading “Frigate NVR on an HP EliteDesk G3 Mini with an i5-6500: Crashes, Workarounds, and an Unexpected Fix”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[23,24,16],"_links":{"self":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/124"}],"collection":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=124"}],"version-history":[{"count":1,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/124\/revisions"}],"predecessor-version":[{"id":125,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=\/wp\/v2\/posts\/124\/revisions\/125"}],"wp:attachment":[{"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=124"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=124"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lfps64.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=124"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\n
\n\n\n\nThe Setup<\/h2>\n\n\n\n
\n\n\n\nThe Problem: i915 Instability Under Load<\/h2>\n\n\n\n
i915<\/code> kernel driver that ranges from “fine” to “spectacular failure” depending on workload, kernel version, and what feels like the phase of the moon.<\/p>\n\n\n\ni915<\/code> driver on Skylake is prone to GPU hangs. The symptoms look like this in the kernel log:<\/p>\n\n\n\ni915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85dffffb\ni915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0\n<\/code><\/pre>\n\n\n\n
\n\n\n\nLiving With It: The Workarounds on Linux Mint<\/h2>\n\n\n\n
\n\n\n\nThe Unexpected Fix: Remove the Desktop<\/h2>\n\n\n\n
i915<\/code> driver with Frigate.<\/p>\n\n\n\n\n
\/dev\/dri\/renderD128<\/code> passed through for VAAPI<\/li>\n\n\n\n
\n\n\n\nWhy Did It Work? (I’m Not Sure)<\/h2>\n\n\n\n
i915<\/code> driver a much quieter workload outside of Frigate’s decode jobs \u2014 and the GPU does seem to be working noticeably less hard now. Less driver state to manage, fewer context switches, less contention. This feels like the most plausible explanation, but it’s still a guess.<\/p>\n\n\n\n
\n\n\n\nCurrent State<\/h2>\n\n\n\n
\n\n\n\nWhat I’d Love to Know<\/h2>\n\n\n\n
\n
i915<\/code> module options that improve stability under sustained decode load?<\/li>\n\n\n\n
\n\n\n\n\/dev\/dri\/renderD128<\/code> passthrough.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"