Bottom Line: Reboot After Deactivating the Disks Before You Start Wiping Metadata
In the solved case, two new 4 TB HDDs worked as standalone disks but RAID 0/1 creation returned a generic exit status 2. No disk replacement or wipe was needed: rebooting ZimaOS after deactivating the drives cleared the stale storage state and RAID creation succeeded. That should be the first low-risk test.
Confirm Both Disks Are Actually Free
lsblk -f
mount
cat /proc/mdstat
Both candidate drives should be unmounted and not already members of another md array or active ZimaOS pool. Do not infer this only from the UI label if creation already failed.
Reboot Once Before Destructive Cleanup
Deactivate the two drives in Storage, reboot ZimaOS, return to Storage, then create RAID again. This is especially useful when the UI/storage service may still hold stale state from the previous standalone configuration.
If It Still Fails, Capture the Real Error
journalctl -xb | tail -200
dmesg | tail -200
exit status 2 is only a wrapper message. The useful cause may be mdadm state, stale filesystem signatures, a mount conflict or another storage-service failure. The Linux mdadm RAID behavior explains the array layer.
Inspect Metadata Before Erasing It
sudo wipefs -n /dev/sdX
sudo mdadm --examine /dev/sdX 2>/dev/null
Use inspection mode first. If you later remove signatures, be certain the disks contain no data you need. Do not make “wipefs -a everything” the default answer to a generic UI error.
Current ZimaOS Supports RAID 0 and RAID 1 Directly
Current storage docs cover RAID 0, RAID 1, RAID 5, RAID 6 and JBOD. RAID 0 requires at least two disks and has no redundancy; RAID 1 mirrors two disks. The ZimaOS RAID levels is the current product reference.
Do Not Use RAID 0 for Data You Cannot Recreate
RAID 0 increases usable capacity and can improve throughput, but one failed member destroys the array. If these 4 TB disks hold media or backups you care about, decide whether RAID 1/5 plus an independent backup is more appropriate.
The ZimaOS backup and RAID recovery cover the failure model.
Verify the New Array Before Loading Data
cat /proc/mdstat
lsblk -f
df -h
Wait for any initialization/resync work to settle, then copy expendable test data first. Reboot once and verify the array returns healthy before committing the only copy of important files.
Disk Size Mismatch Is Not the First Conclusion
Small nominal differences can affect usable size, but in this case the reboot alone solved the problem. Diagnose the actual logs before attributing a generic status code to drive mismatch or hardware failure.
If Metadata Really Is the Problem, Remove Only What You Identified
Linux wipefs signature checks can show filesystem, partition-table and RAID signatures before anything is erased. If the disks are confirmed empty and logs point to stale signatures, remove the specific metadata deliberately, reboot, and retry. This is safer than treating every generic RAID error as permission to wipe both drives immediately.
After cleanup, re-run lsblk -f and mdadm --examine so you know the drives are actually in the state ZimaOS expects before opening the RAID creation flow again.
When the reboot fixes creation immediately, keep that outcome in the incident notes. It is useful evidence that the disks themselves were not proven faulty and that stale service state was the more likely explanation.
FAQ
What does exit status 2 mean in ZimaOS RAID creation?
It is a generic failure result, not a diagnosis. Check logs for the underlying storage or mdadm error.
Should I wipe the drives immediately?
No. Reboot after deactivation first, then inspect metadata before destructive cleanup.
Can brand-new drives have old metadata?
Yes, especially if they were tested or previously partitioned, but prove it with wipefs -n or mdadm --examine.
Is RAID 0 safe for backups?
No. Losing one member loses the array, so keep independent copies.
How do I know the RAID was created correctly?
Check /proc/mdstat, filesystem/mount state, reboot, and verify the array remains healthy.
