Bottom Line: Use the Alternate ZimaOS Slot First, Then Diagnose the Exact Emergency-Mode Dependency
ZimaOS 1.3.2 had a known compatibility problem with some third-party machines in early 2025. In this Proxmox case, Slot A could still boot the older release while the updated slot entered emergency mode. That is exactly what the A/B system design is meant to protect against.
Step 1: Boot the Previous Slot From GRUB
Connect to the console, bring up GRUB with the arrow keys and choose the alternate system slot. Current ZimaOS still uses dual system partitions for quick rollback. The ZimaOS system recovery explains the current process.
RAUC's RAUC slot model provides the underlying slot concept.
Step 2: Read the First Real Failure, Not the Last Emergency-Mode Line
Emergency mode is the consequence. Look above it for the first timed-out device, failed mount or missing dependency. In this case the screen pointed at a storage device before the later dependency failures appeared.
journalctl -xb
systemctl --failed
lsblk -f
cat /etc/fstabStep 3: Check Custom fstab Entries Before Reinstalling
A later branch of the same case exposed an important second cause: manual /etc/fstab changes can block ZimaOS boot when a referenced device is missing or the mount order conflicts with the appliance boot process. IceWhale reported a similar failure involving both /etc/fstab and the persistent overlay copy.
If you added custom RAID or mount entries manually, compare them with the current storage configuration and remove only the entries you understand. Prefer the ZimaOS Storage interface for ordinary RAID and disk mounts.
Why the Old 1.3.2 Driver Bug Is Not a Current Universal Problem
The engineering team acknowledged third-party compatibility issues in that specific release. ZimaOS has moved many releases beyond 1.3.2, so “1.3.2 broke my Proxmox VM” should be treated as historical evidence, not a diagnosis for a 2026 system.
The ZimaOS installation recovery is the modern baseline for third-party x86 hardware.
When a Fresh Install Also Enters Emergency Mode
That is a strong clue that the problem is tied to virtual hardware, attached data disks, persistent mount state or unsupported host configuration—not only the old system partition. Boot with the minimum virtual hardware needed, then add data disks one at a time.
Protect Data Before Editing RAID or Mount Metadata
Do not zero mdadm signatures or recreate arrays while troubleshooting a boot slot. The RAID recovery separates boot recovery from array recovery, while the ZimaOS backup covers the safety layer.
Know What GRUB Can and Cannot Fix
GRUB can choose the previous ZimaOS system slot, but it does not repair a broken data mount or invalid filesystem entry. The GNU GRUB controls explain the bootloader layer. If the previous slot boots, use that working environment to inspect storage configuration and back up data before changing the failed slot.
FAQ
Why does ZimaOS boot the old slot but not the new one?
The old slot still contains the previous working system image. The new slot may have a driver, mount or configuration problem.
Does emergency mode mean my data is lost?
No. It means normal boot dependencies failed. Inspect storage and mount state before assuming filesystem loss.
Can a bad fstab entry prevent ZimaOS boot?
Yes. A mount that cannot be satisfied can block boot or send the system into emergency mode.
Should I reinstall immediately?
No. Try the alternate A/B slot first and capture the first failed dependency. Reinstall only when recovery is not practical.
Is ZimaOS supported in Proxmox?
Virtualized deployments can work, but third-party virtual hardware may expose compatibility differences. Test on the current release and keep a rollback path.
