If both ZimaOS boot slots fail and the console reports overlay mount errors, superblock read failures, or NVMe I/O errors, do not start by rebuilding the storage pool. First determine whether the fault is on the boot device or on the separate data disks.
In this June 2026 case, read-only diagnostics showed repeated media errors on the boot NVMe while the large Btrfs data pool lived on separate disks. The user replaced the boot drive, reinstalled ZimaOS, and later confirmed that the data pool was still there.
First Separate the Boot Device From the Data Pool
The rescue shell output in the thread showed a roughly 119 GB NVMe containing ZimaOS boot/data partitions and a separate multi-disk Btrfs pool. That distinction changed the recovery plan: failure of the boot NVMe did not automatically imply failure of the storage pool.
Start with read-only commands:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineWrite down the exact device names before running any command that targets a disk or partition.
Check Kernel Logs for Real I/O Errors
The source case contained repeated critical medium error, Buffer I/O error, EXT4 mount failures, and NVMe errors against the boot device. Those messages are much stronger evidence of storage failure than a generic boot-screen panic.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'If the errors consistently point to the boot NVMe while the data disks are not reporting faults, keep the investigation focused on the boot path.
A SMART “PASSED” Result Does Not Cancel Media Errors
In the thread, the NVMe SMART health summary still said PASSED, yet the detailed counters showed 76 media/data-integrity errors and the kernel was already logging failed reads. The read-only filesystem check also aborted on unreadable blocks.
Use detailed health data such as smartctl -x /dev/nvmeXn1 or nvme smart-log /dev/nvmeXn1 after confirming the correct device name. Do not treat the single overall health word as the whole diagnosis.
Use Read-Only Filesystem Checks First
The community used e2fsck -fn against the affected EXT4 overlay partition so the filesystem could be inspected without writing repairs. Even that read-only check hit unreadable blocks, reinforcing the hardware-failure diagnosis.
Never run write-mode fsck on a mounted filesystem, and do not guess partition names. If the boot SSD is physically failing, repeated write attempts can make recovery harder.
Why Slot A and Slot B Can Both Fail
ZimaOS uses A/B system slots for recovery, documented in the ZimaOS system recovery guide. But both boot choices still depend on healthy shared storage components on the boot device. A failing overlay or boot NVMe can therefore prevent both slots from completing startup.
When Replacement Is the Safer Path
Once the source case showed kernel media errors, detailed SMART media-error counters, and unreadable filesystem blocks on the boot NVMe, the community advised treating that SSD as untrustworthy rather than trying to repair it in place. The user replaced it and reinstalled ZimaOS successfully.
During reinstall, keep data disks clearly identified and avoid initializing or recreating an existing pool. The ZimaOS installation troubleshooting guide helps with the boot-install side, while the post-reinstall storage recovery guide reinforces the key rule: do not recreate a pool that already contains your data.
Bottom Line
In this case, the kernel panic was a boot-NVMe failure, not proof that the separate data pool was destroyed. Diagnose read-only, confirm which device has the I/O errors, and keep the data disks untouched. The original user replaced the failed boot drive, reinstalled ZimaOS, and confirmed the existing data pool survived.
