vibescoder
cd ..

Friday Fixes: A Model That Found Itself, DNS That Lied for Two Reasons, and a Reboot That Caught a Third

·8 min read
homelabself-hostedhome-automationdebuggingbuilding-in-public

This week wasn’t one fix. It was four, and the interesting part is how little they had in common on the surface. A new local model. An outdated CLI tool. A DNS server making pages hang. A Proxmox host I rebooted on purpose just to see what happened. Different machines, different symptoms, same underlying lesson each time. The thing you assume is working is the thing worth testing.

GLM-4.7-Flash Joins the Lineup, and the Dashboard Catches It Without Being Told

I wanted to add a GLM model to the AI workstation. Z.AI’s flagship GLM-5.x line is a roughly 753-billion-parameter model that needs a multi-GPU rig or hundreds of gigabytes of unified memory, nowhere close to a single consumer card. GLM-4.7-Flash is the variant that fits. It’s a 30B-class mixture-of-experts model with only about 3.6B active parameters per token, comfortably inside the GPU’s headroom at around 17.5GB.

I downloaded a fresh copy rather than reusing an old one, specifically to pick up a GGUF re-upload that fixed a wrong scoring function value, the kind of quiet bug that causes reasoning loops and bad output without ever throwing an error. Wired it into the llama-swap config with the jinja flag GLM’s chat template requires, and a repeat penalty of 1.0, which is Z.AI’s own recommendation for avoiding loop failures.

Then I tested it the way it gets used, not the way it’s convenient to test. A same-box check with two models loaded at once will just run out of VRAM. The real test has to go through the model-swap proxy itself, since that’s what frees memory from the previous model before loading the new one. It did, cleanly, generating around 220 tokens per second and using about two-thirds of available VRAM on its own.

The best part had nothing to do with the model itself. I ran the homelab dashboard’s boot-time freshness check, a feature built weeks ago against the models that existed at the time, and GLM-4.7-Flash showed up on the Models tab with its Hugging Face repo auto-detected straight from the GGUF’s own metadata. No manual mapping entry, no code change. That’s the actual proof a feature works. It’s not that it handles the cases it was built against. It’s that it handles one it had never seen.

While I was in the dashboard, I noticed the status chips on mobile were stuck in an awkward two-column grid, left over from a redesign a few sessions back. Long model and monitor names were getting truncated with an ellipsis and the spacing looked off on a phone screen. Switched it to a single-column flex stack and let labels wrap instead of truncating. Two lines of CSS. Worth mentioning anyway, because it’s a good example of shipping something, looking at it on the device it’s meant for, and fixing what you see rather than guessing at layout from a desktop browser.

Hermes Agent Was 14,455 Commits Behind

I wanted to use the Hermes Agent CLI’s web dashboard. I hadn’t updated the local install since May. Running the version check turned up over fourteen thousand commits of drift, and on top of that, the tool’s default chat model was still pointed at an interim fallback set during an earlier model cleanup, not at anything currently installed.

The fix itself was routine. Stop the background gateway service, back it up, run the built-in update command, which pulls the full git history and reinstalls both the Python and Node dependencies before rebuilding the web UI, then restart the gateway. Pointed the default model at one of the models already on the box and confirmed a real chat request triggered the correct backend load.

The web UI turned up a real design difference. Newer versions of the tool added a hard safety check. They refuse to bind to any address beyond localhost unless an auth provider is configured. There’s no “trust the private network” unauthenticated option, the way the homelab dashboard works. I set up HTTP basic auth with a random generated password so it could be reached from other devices on the network. Not every self-hosted tool treats the network boundary as the security boundary, and it’s worth checking that assumption per tool rather than carrying it over from the last one you configured.

AdGuard Home Was Failing Two Different Ways at Once

Two machines on the network started feeling sluggish. Pages timing out, images not loading. Both routed their DNS through the self-hosted AdGuard Home instance, so that’s where I looked first, starting with the boring check: memory. 84MB used out of 512MB available, no swap pressure, host load average under half a core. Nothing there. The real story was in the service logs, and it turned out to be two unrelated bugs.

The first was a stale cached resolver. AdGuard had been running for two straight days. At some point during that window, the underlying system’s DNS configuration got corrected to point at the LAN router, but AdGuard doesn’t re-read that file live. It caches the system resolver list once, at its own startup, purely for reverse lookups used to show client hostnames in its own interface. Whatever it cached two days earlier included a Tailscale magic-DNS address that this particular box, a plain LAN container with no Tailscale client on it, could never reach. Every single reverse lookup was eating a guaranteed two-second timeout before failing.

The second bug was the one breaking page loads. AdGuard’s only configured upstream resolver was a single DNS-over-HTTPS endpoint, Quad9, with no fallback set at all. A plain curl to that same endpoint from the container succeeded instantly, every time, so the network path itself was fine. But AdGuard’s own DoH client was intermittently hitting an unexpected end-of-file error on that connection, about 78 times in one hour. With no fallback configured, every one of those was an outright resolution failure for whatever domain a page happened to be loading. Different subresources, different domains, different silent failures, spread across a normal browsing session. That’s the actual symptom, explained.

The fix was two config lines and a restart: a real fallback resolver, and an explicit pin on the local reverse-lookup resolver instead of AdGuard’s own stale auto-detection. “Does it just need a reboot” turned out to be half right and half a trap. A reboot would have cleared the stale cache and fixed the first bug. It would have done nothing for the second, and the missing fallback would have left the door open for the next Quad9 hiccup to take pages down again.

A Reboot Test Found the Bug the DNS Fix Couldn’t

Once AdGuard was fixed, the obvious next question was whether the whole box would recover from a real restart, not just a service bounce. Better to find that out on purpose than during a real outage. The Proxmox host in question runs four things: a Home Assistant VM, and three LXC containers for AdGuard, an uptime monitor, and a homelab status dashboard.

Before touching anything, I checked each workload’s onboot flag, since that’s the setting that controls what comes back after a host-level reboot. A container running right now says nothing about whether it survives a cold boot. All three LXC containers had it set correctly. The Home Assistant VM did not. Nobody had ever noticed, because that VM had simply never been rebooted since it was first set up.

Set the flag, captured a baseline HTTP check against all four services, then rebooted the host for real. It came back in about 80 seconds. All four services, Home Assistant included this time, auto-started and were answering requests within a minute, matching the baseline exactly. The DNS fix from earlier in the day persisted cleanly through the reboot too, confirmed by resolving a real domain immediately after.

One more small thing turned up in the process. AdGuard logged two “network unreachable” errors in the very first second of its own container starting, trying to reach the LAN router before its own interface had finished coming up. It resolved itself instantly and never happened again, a systemd startup ordering issue rather than a config bug. Filed away as a nice-to-have, not urgent.

None of This Would Have Shown Up in a Status Check

Each of these four problems hid behind a status that looked fine. A running VM says nothing about whether it survives a reboot. A DNS server answering some queries says nothing about whether the one upstream it depends on is reliable. A feature works until it meets a model it wasn’t built against. The only way to know any of that is to test it, on purpose, before the day it matters instead of during it.

What’s the one thing in your own setup you’re assuming works, but haven’t tested since the day you set it up?

By the Numbers

  • 1 new local model added and validated end to end, auto-detected by a feature that had never seen it before
  • 17.5GB GLM-4.7-Flash download, running at roughly 220 tokens per second solo
  • 14,455 commits pulled in a single Hermes Agent update
  • 2 unrelated bugs found stacked inside one “AdGuard is slow” symptom
  • 78 DNS-over-HTTPS failures against the sole upstream in one hour, with zero fallback configured
  • 1 VM found silently missing its onboot flag, years after setup
  • 4 of 4 services back up and matching baseline within about 60 seconds of a real host reboot
  • ~80 seconds total downtime for the reboot test itself

Comments