Since v1.6.2 my server cannot update to newer versions of ZimaOS (tried 1.7.0). The update process appears to run, but the server fails to boot into the new slot, and after 3 failed boot attempts RAUC automatically falls back to the previous slot (marked Bad). The failed boots die almost immediately with no error, panic, or graceful shutdown logged anywhere. I have tried looking in the forums and Discord for similar problems and troubleshooting using AI and the following is the summary of that.
Setup
My current working version: 1.6.2 (slot A)
Attempted update: 1.7.0 (slot B - fails)
Hardware: Repurposed Chromebook
Firmware: MrChromebox custom UEFI firmware, version MrChromebox-4.14
CPU: Intel Core i3-5005U (Broadwell)
Storage: Single SATA SSD (TS120GMTS420S, 120GB)
Kernel on slot B: Linux 6.18.9
I'm flagging the hardware explicitly because I found a Github issue describing a similar "slot B marked Bad" symptom, but that case was resolved by disconnecting a second NVMe SSD - I don't have a second SSD, so I don't believe it's the same root cause. Given my somewhat non-standard hardware, this may be specific to this platform but I wanted to report it in case it points to something useful and can be resolved.
Steps to reproduce
- On 1.6.2,
run zimaos -u 1.7.0 (also tried via the web UI - same result)
- Server reboots to apply the update, boots into slot B
- Boot dies almost immediately, screen flashes, server hard-resets
- This repeats 3 times, then RAUC automatically falls back to slot A
rauc status shows slot B marked Bad
journalctl --list-boots confirms a crash loop with each boot lasting around 3-4 seconds.
Looking at one failed slot B boot, the kernel boots normally but the log simply stops right after USB/keyboard enumeration, about 3 seconds after kernel start. There is no kernel panic, no error-level messages (journalctl -b -1 -p err shows nothing relevant), no systemd shutdown/reboot sequence logged and no dump in /sys/fs/pstore/.
Full kernel log from a failed boot
### What I've already ruled out
-
nomodeset kernel parameter - no effect, boot still dies at the same point.
-
intel_idle.max_cstate=1 processor.max_cstate=1 (testing for a known Broadwell+coreboot deep C-state reset bug) - no effect.
-
Second NVMe SSD conflict - not applicable, I only have one SATA SSD, no NVMe installed.
Is ZimaOS 1.7.0's kernel expected to work on Chromebook hardware running MrChromebox firmware? Given the immediate, silent, hard-reset nature of the failure with zero trace in kernel/systemd logs or pstore, I'm clueless at what the issue is, so any pointers on what to check next would be appreciated.
Since v1.6.2 my server cannot update to newer versions of ZimaOS (tried 1.7.0). The update process appears to run, but the server fails to boot into the new slot, and after 3 failed boot attempts RAUC automatically falls back to the previous slot (marked Bad). The failed boots die almost immediately with no error, panic, or graceful shutdown logged anywhere. I have tried looking in the forums and Discord for similar problems and troubleshooting using AI and the following is the summary of that.
Setup
My current working version: 1.6.2 (slot A)
Attempted update: 1.7.0 (slot B - fails)
Hardware: Repurposed Chromebook
Firmware: MrChromebox custom UEFI firmware, version MrChromebox-4.14
CPU: Intel Core i3-5005U (Broadwell)
Storage: Single SATA SSD (TS120GMTS420S, 120GB)
Kernel on slot B: Linux 6.18.9
I'm flagging the hardware explicitly because I found a Github issue describing a similar "slot B marked Bad" symptom, but that case was resolved by disconnecting a second NVMe SSD - I don't have a second SSD, so I don't believe it's the same root cause. Given my somewhat non-standard hardware, this may be specific to this platform but I wanted to report it in case it points to something useful and can be resolved.
Steps to reproduce
run zimaos -u 1.7.0(also tried via the web UI - same result)rauc statusshows slot B marked Badjournalctl --list-bootsconfirms a crash loop with each boot lasting around 3-4 seconds.Looking at one failed slot B boot, the kernel boots normally but the log simply stops right after USB/keyboard enumeration, about 3 seconds after kernel start. There is no kernel panic, no error-level messages (
journalctl -b -1 -p errshows nothing relevant), no systemd shutdown/reboot sequence logged and no dump in/sys/fs/pstore/.Full kernel log from a failed boot
### What I've already ruled out
nomodesetkernel parameter - no effect, boot still dies at the same point.intel_idle.max_cstate=1 processor.max_cstate=1(testing for a known Broadwell+coreboot deep C-state reset bug) - no effect.Second NVMe SSD conflict - not applicable, I only have one SATA SSD, no NVMe installed.
Is ZimaOS 1.7.0's kernel expected to work on Chromebook hardware running MrChromebox firmware? Given the immediate, silent, hard-reset nature of the failure with zero trace in kernel/systemd logs or pstore, I'm clueless at what the issue is, so any pointers on what to check next would be appreciated.