The source problem was not “the Storage page forgot to show four SSDs.” ZimaOS 1.6.1 could enumerate the Broadcom/LSI MegaRAID controller, but the controller failed during Linux driver initialization, so none of the four attached SSDs appeared as block devices in lsblk. Until the disks exist as /dev/sdX, the ZimaOS Storage UI has nothing reliable to combine or enable.
The strongest comparison came at the end: Ubuntu 22.04.4 on the same machine could see the HBA and attached disks, while ZimaOS 1.6.1 still failed. That made a controller-driver/kernel compatibility issue much more likely than bad SSDs or user Storage settings. Current IceWhale documentation now lists LSI RAID adapters, LSI Logic MegaRAID SAS RAID, and LSI HBA support as implemented community-requested drivers—but the original poster never verified this exact M1210 on a later ZimaOS release.
lsblk Showed Only the NVMe System Disk
The source user's lsblk output contained the 512 GB NVMe system disk but no /dev/sdX devices for the four 4 TB SSDs.
That immediately moves troubleshooting below the ZimaOS Storage UI.
lspci Confirmed the HBA Itself Was Detected
The controller appeared as:
Broadcom / LSI MegaRAID SAS-3 3008 [Fury]So the PCIe device was visible. The missing layer was successful driver/firmware initialization and SCSI/block-device exposure.
dmesg Captured the Critical Driver Failure
Early logs included:
FW in FAULT state
Failed to transition controller to ready
Failed from megasas_init_fwAfter firmware/controller work, the card reached FW now in Ready state but still failed the initialization command for SCSI host 0. The four SSDs still never reached lsblk.
The Controller BIOS Could See All Four JBOD Drives
Ubuntu Live Was the Decisive Hardware Comparison
The same HBA and SSDs were visible under Ubuntu 22.04.4 LTS. That means the hardware path was basically functional and makes “all four drives are bad” very unlikely.
When one Linux distribution sees the disks and another only sees the controller, compare kernel/module/firmware support before reformatting the drives.
Old TrueNAS Metadata Was Not the Final Explanation
The user had previously run TrueNAS and created a RAID volume, so old partition/metadata was reasonably considered. But old filesystem metadata would normally still leave the physical disks visible in lsblk. Here, no SSD block devices existed at all under ZimaOS.
Current IceWhale Documentation Lists LSI/MegaRAID/HBA Support as Implemented
IceWhale's current contributions page now lists:
- LSI RAID adapter;
- LSI Logic MegaRAID SAS RAID;
- LSI HBA
under implemented driver requests.
See the current ZimaOS driver contribution list.
Retest the Exact M1210 on Current ZimaOS Before Declaring It Unsupported
Current ZimaOS is 1.7.1. The correct current check is to boot/update, then compare:
lspci -nnk
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT
dmesg | grep -i -E "megaraid|mpt3sas|sas|scsi|error|fail"If the disks now appear, proceed to Storage. If the same initialization failure remains, report the exact PCI ID, firmware version, current kernel, and Ubuntu comparison to IceWhale.
The Storage UI Can Only Manage Disks the Kernel Exposes
One confusing detail in the source was that the ZimaOS UI appeared to show a single drive-like entry even though lsblk still showed no SSDs behind the HBA. That is why the command-line evidence mattered more than the visual placeholder. Until Linux exposes the disks as block devices, clicking Combine/Enable cannot create a reliable array.
Controller Mode Still Matters Even When JBOD Is Reported
The M1210 BIOS reported four JBODs and zero virtual drives, which is the correct general direction for software-defined storage. But controller firmware, cached foreign configuration, personality/mode, and driver expectations can still prevent Linux from receiving normal disks. Treat “JBOD shown in BIOS” as necessary evidence, not absolute proof of operating-system passthrough.
Changing Firmware Changed the Error but Did Not Complete Initialization
After the user worked on the controller firmware, dmesg progressed from an outright firmware fault to “FW now in Ready state.” The next initialization command still failed. That progression is valuable because it shows the card was not completely dead, while also proving the firmware update alone did not solve the ZimaOS 1.6.1 compatibility problem.
Do Not Reinitialize Old TrueNAS Disks Until the HBA Layer Is Stable
The four SSDs previously belonged to a TrueNAS storage setup. If any data still matters, avoid creating new arrays, clearing metadata, or formatting drives merely to make them appear in ZimaOS. First get consistent block-device visibility under the current OS, then decide whether the old data should be imported, backed up, or erased.
LSI HBA Detection FAQ
Did the source prove the SSDs themselves were dead?
No. The HBA BIOS and Ubuntu both saw the attached drives.
Was this primarily a ZimaOS Storage UI problem?
No. The disks did not exist in lsblk, so the failure was below the UI.
Did the original poster confirm the exact M1210 works on current ZimaOS?
No. The thread ended on 1.6.1 before that confirmation.
