The board had been on v1.5.4-alpha2 since the January reinstall. An alpha, eight months old, two minor versions behind, and the first release note for 1.7.1 is a high-risk security fix in file services.

The built-in updater was never going to offer it. Its release/latest endpoint answers no release, and release/current hangs for two minutes. The board reaches GitHub fine, so this is the alpha’s update checker watching a track with nothing newer on it. The documented offline route didn’t fire either: the 1.7.1 bundle sat in /DATA/.ota/offline/ at the correct size with its hash verified, and after ten minutes there was still no red dot in the UI.

100% on / is normal here

This is the number I should stop being scared of. The root filesystem reads 100 percent full, with zero available.

On ZimaOS the root is a read-only image sized exactly to its contents, so it always reads full. Updates don’t touch it anyway. ZimaOS uses RAUC A/B slots: it writes the new system to the inactive slot, boots into it, and falls back to the old one if that fails. What matters for an update is /DATA, which had 14 GB free against a 1.5 GB bundle.

That makes me look sideways at something I published. In the write-up of January’s failed migration I called root filesystem exhaustion the first domino, and told readers to keep headroom on the system partition. I can’t re-run January, so I’m not retracting it. But a root that reads 100 percent is available as an explanation on this system every single day, and I now wonder how much of that diagnosis was the same red herring.

Ask before installing, with commands that change nothing

sudo rauc status                 # which slot is booted, and each slot's health
sudo rauc info <bundle>.raucb    # verifies the signature, prints compatible + version

rauc info verified the bundle’s signature against the board’s own keyring, IceWhale Technology Development-1, and showed zimaos-zimacube as the compatible string on both sides. Learning that from a read-only command beats learning it halfway through an install.

rauc status also showed slot B marked bad. At some point a system in B had failed to boot and the board had fallen back to A, almost certainly in January. I found that reassuring rather than worrying: the fallback I was about to rely on had already saved this exact board once.

The install

The direct route is the same mechanism the red dot drives:

sudo rauc install /DATA/.ota/offline/zimaos-x86_64-1.7.1.raucb
sudo reboot

It came back booted from B with status good, so the old bad mark belonged to the previous image and not to the partition. Slot A still holds 1.5.4 as a fallback. The web UI’s build date moved from 7 January to 21 August 2026, the 1.7.1 release date.

Everything survived, including the two containers I was worried about. They are plain docker run containers rather than ZimaOS apps, so nothing would recreate them if Docker’s state were reset. Both came back on their restart policies, all five managed apps were running, and all 16 of my uptime monitors were green. Beforehand I had exported every app’s compose definition to a directory outside git at mode 600, since two of them carry database passwords.

The ZimaOS 1.7.1 dashboard with the System widget expanded, listing seven containers by name with their CPU use, including two that ZimaOS does not manage, beside app tiles for Immich, Paperless-ngx, Uptime Kuma, Tailscale and Homepage

One job is left: the 1.5 GB bundle is still in /DATA/.ota/offline/, on a partition that is only 17 GB.

If an appliance tells you there is no update, that is a statement about the track its checker watches, not about the software. The A/B design meant the step that looked most dangerous, installing an OS image by hand, was the one with a way back built in.