Skip to content
buddy-cluster.dev

Keeping Buddy Cluster updated

“Couldn’t check for updates”

What it means: Buddy checks a single small file over the internet, once a day and whenever you choose Check now, to see whether a newer version has been published. If it can’t reach that address, or what it gets back doesn’t check out, the card says so instead of guessing — it never shows “you’re up to date” unless it’s actually confirmed that.

This is expected, not a fault, on a cluster with no route to the internet: turn the check off in Cluster → Advanced rather than leaving it retrying forever, and update by hand instead (see Keep the cluster’s software up to date).

Right now it’s also expected on every cluster, internet or not: the update feed isn’t accepting real update notices yet, so a check always ends this way. There’s nothing wrong with your cluster or your connection — download and install new releases the usual way (re-running the installer, or from Keep the cluster’s software up to date) until this changes.

Fix: Nothing to fix if you’re on an air-gapped or otherwise offline cluster — this is the correct, supported state for it. Otherwise, choose Check now on Cluster → Advanced later; once the feed is accepting real notices, a working connection will start showing “Update available” on its own.

If that didn’t work: If you’re certain your cluster has a working internet connection and this message never clears even after some time, export a diagnostics bundle and check the master’s own log (sudo journalctl -u buddy-server -f) for what the check is actually failing on.

The update failed and the panel came back on an older version

What it means: Choosing Update now downloads a new release, checks it thoroughly, and only then installs it. If any of that doesn’t go cleanly — the download doesn’t check out, the new version never finishes starting, anything short of a clean success — Buddy puts everything back exactly as it was: the previous management software and the previous copy of its own records, automatically, before you’d even notice something was wrong. The panel reappears on the version you were already running and a card explains what happened.

Nothing on your nodes or in your workloads is affected either way — this is entirely about the master’s own management software and its own records, not what’s running on your cluster.

Fix: Nothing to do — the restore already happened by the time you see this. The card names why it failed; if it’s not obvious what to do next from that alone, wait for a later release and try again, or update by hand instead (see Keep the cluster’s software up to date).

If that didn’t work: If the panel doesn’t come back at all after several minutes, that’s the one case nothing automates: the machine most likely lost power partway through, before it could put anything back itself. Recover it by hand, over SSH (or on the machine directly):

Terminal window
# 1. Find the previous management software, saved before the attempt started:
ls /var/lib/buddy-server/rollback/
# → a directory named after your previous version, e.g. 0.0.22/
# 2. Put it back:
sudo cp /var/lib/buddy-server/rollback/<that-version>/buddy-server /usr/local/bin/
sudo cp /var/lib/buddy-server/rollback/<that-version>/buddy-agent /usr/local/bin/
# 3. Put back the matching copy of Buddy's own records, newest first:
ls -t /var/lib/buddy-server/buddy.db.pre-* | head -n1
sudo rm -f /var/lib/buddy-server/buddy.db-wal /var/lib/buddy-server/buddy.db-shm
sudo cp <that file> /var/lib/buddy-server/buddy.db
# 4. Restart:
sudo systemctl restart buddy-server buddy-agent

This is a destructive recovery step, not a routine one. Use it only when the panel genuinely never comes back after an update — not as a first response to a normal, momentary blip.

If step 3 finds no buddy.db.pre-* file at all, the new management software never got far enough to touch its own records in the first place — skip that step; there’s nothing to restore there.

The panel is unreachable for a few minutes after choosing “Update now”

What it means: This is expected, every time. Buddy’s management software restarts as part of installing itself, so the panel — and anything else that talks to the master directly, like an SSH session running a command against it — briefly can’t be reached. Your nodes and whatever they’re running keep going the whole time; this is only the part of Buddy Cluster that manages them.

Fix: Wait a few minutes and reload. The update card itself picks its progress back up on its own once the panel is reachable again — there’s no need to keep the page open or refreshing it while you wait.

If that didn’t work: If the panel stays unreachable for much longer than a few minutes, see “The update failed and the panel came back on an older version,” above — specifically its by-hand recovery note for the case where the machine lost power.

My nodes are still on the old version after updating the master

What it means: Updating the master and updating your nodes are two separate, deliberate steps. Once the master finishes updating, the Dashboard shows a card offering to bring your nodes up to match — it never starts that on its own, the same way installing a node’s own updates is never automatic either.

Fix: Choose Update agents on that card, or open Cluster → Agent and start the update from there directly. See Keep the cluster’s software up to date for the rest of that flow.

If that didn’t work: See Updating buddy-agent for symptoms specific to that part of the process.