I can't update to 1.6.2

Insight & Feedback
,
1

Hello everyone.
Impossible to update to 1.6.2 on my Zimacube 1.

I can do the update, it reboots, I have the “What’s new on 1.6.2” popup, but I’m still on 1.6.1 !

2

I tried this and no change : [Tutorial] ZimaOS Installation and Upgrade Guide

3

Please try updating offline.

4

I tried it, it put the raucb file in /ZimaOS-HD/.ota/offline/

But I never have another update icon (I just have the regular one, which I tried, it did not work again)

5

1.7.0 is out and I have the exact same problem… :frowning:

6

Following up on this thread. I dug into this over SSH and wanted to share what I found in case it helps others or the ZimaOS team.

rauc status on my Zimacube 1 (currently stuck on 1.6.1):

Booted from: kernel.0 (A)
Activated: kernel.0 (A)

[kernel.0] bootname: A, boot status: good, booted
[kernel.1] bootname: B, boot status: bad, inactive

Slot B has been marked bad by the bootloader, which explains why every update attempt “succeeds” from the UI’s perspective but the system keeps rebooting into the old A slot.

Steps taken so far:

  1. journalctl --list-boots + journalctl -b <offset> -p err on the short boots around update attempts: no rauc/grub-editenv/mnt-boot errors, no useful trace at all. Whatever fails on slot B fails before persistent logging kicks in.

  2. Tried rauc status mark-active kernel.1 + reboot: system took over 10 minutes to come back, ended up back on A with B still marked bad. No confirmation it even tried B.

  3. Downloaded the official bundle and ran a full manual reinstall directly via SSH: sudo rauc install zimaos-x86_64-1.7.0.raucb. This completed successfully end to end (boot.0, kernel.1, rootfs.1 all rewritten, “Installing done”).

  4. Rebooted after the clean reinstall: still stuck on A, still doesn’t boot into B.

So this isn’t bundle/package corruption. Slot B gets a fully clean, freshly-written image and still fails to boot or gets reverted. This points to something at the bootloader/GRUB level rather than the update package itself.

The end symptom (slot B permanently marked bad, silent fallback to A) resembles what’s described in GitHub issue #478 (mnt-boot.mount / grub-editenv failures during early boot), though I can’t confirm it’s the same root cause since my logs don’t show those specific errors, the failure happens too early to get captured.

One detail that might be relevant on my end: I also see nvme nvme1: Device not ready; aborting reset, CSTS=0x1 in the journal on normal boots on A too, so there may be an NVMe timing/reset issue on this hardware interacting badly with the A/B boot-attempt window.

I don’t have physical console access to this unit right now, so I can’t see what actually happens on screen during a B boot attempt, that’s the next thing I’ll try to arrange. Has anyone from the team looked into what causes slot B to get marked bad in general? Happy to provide more logs/output if useful.

7

Update, issue resolved!

The final piece came from getting physical console access. On boot, slot B was hitting a kernel panic:

lsblk: /dev/nvme0n1p5
/dev/nvme1n1p5: not a block device
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00002000

So it wasn’t a bootloader/RAUC bug at all in my case, it was a hardware timing issue. I have a second NVMe SSD in the front bay of the Zimacube 1, and it was enumerating too slowly/inconsistently at boot (I’d also seen nvme nvme1: Device not ready; aborting reset, CSTS=0x1 in the journal on normal boots on slot A). On slot A it apparently just barely made it in time, but on slot B the init script hit the missing device and panicked outright.

Fix: I removed that front-bay NVMe SSD, and the update went through immediately after. System is now happily on the new version.

Thanks for the help along the way. Hope this helps anyone else who runs into a “stuck on old version” update loop, especially if you’ve got extra NVMe drives in the front bay, it might be worth checking their enumeration timing before assuming it’s a software/RAUC issue.

9

Thank you for the detailed investigation and follow-up. We’re glad to see from your latest post that you were able to resolve the issue.

When two drives containing ZimaOS installations are connected at the same time, the corresponding partitions on both drives may have identical filesystem UUIDs. During early boot, ZimaOS uses these UUIDs to locate and mount the required system partitions. If the same UUID exists on two different drives, the system cannot reliably determine which partition belongs to the system drive that is currently being booted.

As a result, a partition from the other drive may be selected, multiple devices may be returned for the same UUID, or system partitions from different drives may be mounted unexpectedly. This can cause mount failures, a kernel panic, an update rollback, or other boot issues.

The following error you captured is also consistent with duplicate UUIDs causing the partition lookup to return both devices instead of one:

lsblk: /dev/nvme0n1p5 /dev/nvme1n1p5: not a block device

In this case, the RAUC installation itself completed successfully. The apparent update failure occurred afterward because the newly updated B slot could not complete the boot process, so the system marked it as bad and fell back to the previous A slot.

We recommend keeping only one ZimaOS system drive connected during an update or system boot. If the second drive is intended to be used only for data storage, please back up any required data and remove the old ZimaOS partitions or reformat the drive before reconnecting it, so that duplicate system partition UUIDs are no longer present.