Källproblemet var inte att ”lagringssidan glömde att visa fyra SSD:er”. ZimaOS 1.6.1 kunde identifiera Broadcom/LSI MegaRAID-styrenheten, men styrenheten misslyckades under initieringen av Linux-drivrutinen, så ingen av de fyra anslutna SSD:erna visades som blockenheter i lsblk. Förrän diskarna finns som /dev/sdX, ZimaOS lagringsgränssnitt har inget tillförlitligt att kombinera eller aktivera.
Den starkaste jämförelsen kom i slutet: Ubuntu 22.04.4 på samma maskin kunde se HBA:n och de anslutna diskarna, medan ZimaOS 1.6.1 fortfarande misslyckades. Det gjorde att ett kompatibilitetsproblem med styrenhetens drivrutin eller kärna blev mycket mer sannolikt än trasiga SSD:er eller användarens lagringsinställningar. Aktuell dokumentation från IceWhale listar nu LSI RAID-adaptrar, LSI Logic MegaRAID SAS RAID och LSI HBA-stöd som implementerade drivrutiner efter önskemål från communityn – men det ursprungliga inlägget verifierade aldrig denna exakta M1210 på en senare ZimaOS-version.
lsblk visade endast NVMe-systemdisken
Källanvändarens lsblk utdata innehöll NVMe-systemdisken på 512 GB men ingen /dev/sdX enheter för de fyra 4 TB stora SSD:erna.
Det flyttar omedelbart felsökningen till under ZimaOS lagringsgränssnitt.
lspci bekräftade att själva HBA:n hade identifierats
Styrenheten visades som:
Broadcom / LSI MegaRAID SAS-3 3008 [Fury]PCIe-enheten var alltså synlig. Det som saknades var lyckad initiering av drivrutin och fast programvara samt exponering av SCSI- och blockenheter.
dmesg fångade det kritiska drivrutinsfelet
Tidiga loggar innehöll:
Den fasta programvaran är i läget FAULT
Misslyckades med att överföra styrenheten till läget Ready
Misslyckades från megasas_init_fwEfter arbete med den fasta programvaran och styrenheten nådde kortet Den fasta programvaran är nu i läget Ready men misslyckades ändå med initieringskommandot för SCSI-värd 0. De fyra SSD:erna nådde fortfarande aldrig lsblk.
Styrenhetens BIOS kunde se alla fyra JBOD-diskarna
Ubuntu Live var den avgörande jämförelsen av hårdvaran
Samma HBA och SSD:er var synliga under Ubuntu 22.04.4 LTS. Det innebär att hårdvaruvägen i grunden fungerade, vilket gör att ”alla fyra diskar är trasiga” är mycket osannolikt.
När en Linuxdistribution ser diskarna och en annan bara ser styrenheten bör du jämföra stöd för kärna, moduler och fast programvara innan du formaterar om diskarna.
Gamla TrueNAS-metadata var inte den slutliga förklaringen
Användaren hade tidigare kört TrueNAS och skapat en RAID-volym, så gamla partitioner och metadata övervägdes med goda skäl. Men gamla filsystemmetadata skulle normalt ändå lämna de fysiska diskarna synliga i lsblk. Här fanns det överhuvudtaget inga SSD-blockenheter under ZimaOS.
Aktuell IceWhale-dokumentation listar stöd för LSI/MegaRAID/HBA som implementerat
IceWhales aktuella bidragssida listar nu:
- LSI RAID-adapter;
- LSI Logic MegaRAID SAS RAID;
- LSI HBA
under implementerade drivrutinsförfrågningar.
Se den aktuella listan över ZimaOS-drivrutinsbidrag.
Testa just M1210 igen med nuvarande ZimaOS innan du förklarar det som inkompatibelt
Nuvarande ZimaOS är 1.7.1. Den korrekta aktuella kontrollen är att starta om/uppdatera och sedan jämföra:
lspci -nnk
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT
dmesg | grep -i -E "megaraid|mpt3sas|sas|scsi|fel|fail”Om diskarna nu visas kan du gå vidare till Lagring. Om samma initieringsfel kvarstår bör du rapportera exakt PCI-ID, firmwareversion, aktuell kärna och Ubuntu-jämförelsen till IceWhale.
Lagringsgränssnittet kan bara hantera diskar som kärnan exponerar
En förvirrande detalj i källan var att ZimaOS gränssnitt verkade visa en enda diskliknande post trots att lsblk visade fortfarande inga SSD:er bakom HBA:n. Därför var kommandoradsbevisen viktigare än den visuella platshållaren. Innan Linux exponerar diskarna som blockenheter kan ett klick på Kombinera/Aktivera inte skapa en tillförlitlig array.
Styrenhetens läge spelar fortfarande roll även när JBOD rapporteras
M1210:ans BIOS rapporterade fyra JBOD-enheter och noll virtuella enheter, vilket är rätt övergripande riktning för programvarudefinierad lagring. Men styrenhetens firmware, cachad främmande konfiguration, personlighet/läge och drivrutinernas förväntningar kan fortfarande hindra Linux från att ta emot normala diskar. Se ”JBOD visas i BIOS” som nödvändiga belägg, inte som ett absolut bevis på genomkoppling till operativsystemet.
Ändrad firmware ändrade felet men slutförde inte initieringen
Efter att användaren arbetat med styrenhetens firmware, dmesg gick från ett direkt firmwarefel till ”FW now in Ready state”. Nästa initieringskommando misslyckades fortfarande. Den utvecklingen är värdefull eftersom den visar att kortet inte var helt dött, samtidigt som den bevisar att firmwareuppdateringen ensam inte löste kompatibilitetsproblemet med ZimaOS 1.6.1.
Återinitiera inte gamla TrueNAS-diskar innan HBA-lagret är stabilt
De fyra SSD:erna tillhörde tidigare en TrueNAS-lagringskonfiguration. Om någon data fortfarande är viktig bör du undvika att skapa nya arrayer, rensa metadata eller formatera diskarna bara för att få dem att visas i ZimaOS. Börja med att få konsekvent synlighet för blockenheterna i det nuvarande operativsystemet och avgör därefter om de gamla data ska importeras, säkerhetskopieras eller raderas.
Vanliga frågor om identifiering av LSI HBA
Visade källan att SSD:erna själva var trasiga?
Nej. Både HBA:ns BIOS och Ubuntu såg de anslutna enheterna.
Var detta främst ett problem med ZimaOS lagringsgränssnitt?
Nej. Diskarna fanns inte i lsblk, så felet låg under användargränssnittet.
Bekräftade den ursprungliga skribenten att just M1210 fungerar med nuvarande ZimaOS?
Nej. Tråden slutade på 1.6.1 före den bekräftelsen.
