If ZimaOS appears to install an update successfully but reboots into the old version, treat it as a boot-selection problem before treating it as a download problem. The most useful checks are the active RAUC slot, whether the newly written slot is marked bad, and whether another connected drive contains an old ZimaOS installation or duplicate filesystem identifiers.
A verified community case looked like a failed 1.6.2 upgrade at first, but the update bundle itself was valid. The machine wrote the new system to the alternate slot, failed to boot it, then fell back to the previous slot. A second NVMe containing old ZimaOS partitions was the key factor. That distinction matters because repeatedly downloading the same update would never fix the boot path.
How to Recognize an Update Rollback
The classic pattern is:
- the updater reaches completion;
- the device reboots;
- the dashboard still reports the old version;
- the update notification appears again;
- offline update or a direct RAUC install also appears to succeed.
If the installer reports a hard checksum or signature error before writing anything, that is a different problem. But when writing succeeds and the old system returns after reboot, focus on the next boot stage.
Step 1: Check the Current System Slot
ZimaOS uses two small system partitions, Slot A and Slot B, so one slot can be updated while the other remains available for recovery. The current ZimaOS system recovery guide documents this dual-slot architecture.
From the terminal, inspect the RAUC status and note which slot is booted, which one is active, and whether the updated slot is considered good or bad. A slot that was written successfully but becomes bad after boot tells you the failure is occurring after installation.
Step 2: Attach a Monitor Before Forcing Another Update
A web dashboard cannot show early-boot failures that occur before networking and the ZimaOS UI start. Connect a monitor and keyboard, reboot, and watch for GRUB, filesystem, NVMe, UUID, or kernel errors.
If the alternate slot crashes and the system automatically returns to the old slot, photograph the error. That is much more actionable than another screenshot of the updater showing 100%.
Step 3: Inventory Every Attached Boot-Capable Drive
A common blind spot is a second SSD or NVMe that used to run ZimaOS. Even if you now intend to use it only as storage, it may still contain boot partitions, duplicate filesystem UUIDs, or an old bootloader.
Temporarily disconnect secondary system-capable drives
Shut the machine down cleanly and leave only the intended ZimaOS system disk connected, plus any data disks that you know never carried another ZimaOS installation. Then test the update again.
Do not erase a drive until the diagnosis is proven
If removing a specific secondary drive makes the new slot boot normally, back up any data on that drive before deleting old system partitions. The verified source case was solved by removing the conflicting NVMe; that does not mean every failed update should immediately be followed by a disk wipe.
Step 4: Use Offline Update Only When It Solves the Right Problem
The current ZimaOS offline update guide is useful when the normal update channel cannot fetch or stage the package, but offline installation will not fix a boot conflict caused by duplicated system partitions.
If online and offline installation both write successfully yet the system keeps reverting, stop repeating the installer and move deeper into boot diagnostics.
Do Not Force a Bad Slot Active Without Understanding the Failure
It can be tempting to mark the new slot good or force it active. That may turn an automatic rollback into a machine that no longer reaches the dashboard. Let the fallback mechanism protect you while you collect evidence.
The ZimaOS troubleshooting checklist is a useful broader checklist when the device will not boot reliably.
When Is Reinstalling ZimaOS Reasonable?
Reinstall is appropriate when both system slots are damaged, the system disk has filesystem or hardware problems, or you cannot restore a bootable slot after eliminating drive conflicts. It should not be the first response to a rollback when the old slot still boots normally.
Before reinstalling, confirm that user data and AppData on separate storage are backed up. If app data lives on the system disk, protect it first.
How to Prevent This on a Multi-Drive Server
- Keep only one intended ZimaOS system installation connected during upgrades or system migration.
- When repurposing an old ZimaOS SSD as data storage, back it up and remove obsolete system partitions before returning it to service.
- Label system drives physically so an old boot disk is not reintroduced months later.
- Keep AppData and user data on dedicated storage so reinstalling the OS is less disruptive.
The app data planning guide helps reduce the cost of a future OS recovery.
FAQ
Why does ZimaOS say the update succeeded but still show the old version?
The update may have been written to the alternate slot successfully, but that slot may have failed to boot. ZimaOS can then return to the previous working slot.
Does a bad RAUC slot always mean the update file is corrupt?
No. A slot can become bad because of boot-time storage, filesystem, kernel, or hardware problems even when the update bundle was valid.
Can a second SSD with an old ZimaOS installation interfere with boot?
Yes. The verified source case involved another NVMe containing old ZimaOS-style partitions and conflicting identifiers. Test by removing secondary boot-capable drives before erasing anything.
Should I reinstall immediately?
Not if the previous slot still boots. First inspect slot status, console output, and attached drives. Reinstall after the cause is understood or when neither slot is recoverable.
