Källhandledningen från 2024 behandlade ett kompatibilitetsproblem med visning/mappning på maskinvara som inte var ZimaCube. Den förutsatte att SATA- eller NVMe-enheten redan kunde identifieras av Linux-verktyg som lsblk eller lspci, men att ZimaOS lagringsskåp inte mappade tredjepartsstyrenhetens layout korrekt.
Den skillnaden är viktig i dag eftersom nuvarande ZimaOS sedan dess har fått flera korrigeringar för lagring från tredje part. I ZimaOS 1.4.4 korrigerades uttryckligen problemet med att NVMe-diskar från tredje part visades som saknade i Lagring, och i 1.6.1 optimerades visningslogiken för diskskåp på tredjepartsmaskiner med många diskar. Uppdatera först innan du redigerar den historiska konfigurationsfilen.
Den historiska SATA-korrigeringen använde SataStartNumber
Den officiella källan instruerade SATA-användare att kontrollera styrenhetens adressering med:
lsblk -o hctloch redigera sedan /etc/casaos/local-storage.conf så att SataStartNumber stämde överens med den HCTL-numrering som datorn förväntade sig.
Den historiska NVMe-korrigeringen använde PCI-adresser
För NVMe-enheter använde källan lspci för att identifiera PCI-adresser och placerade dem i NVME fältet i samma konfigurationsfil innan omstart zimaos-local-storage.
Tråden innehåller en verklig oenighet om avgränsaren
Den officiella texten från 2024 säger att flera NVMe-adresser ska separeras med kommatecken. I oktober 2025 rapporterade en användare i communityt att kommatecken inte fungerade på deras system och att mellanslag gjorde det.
Denna motsägelse bör finnas kvar. Den visar att det manuella filformatet eller parserbeteendet ändrades eller skilde sig mellan versioner; den är inte ett skäl att förklara en viss avgränsare som universellt korrekt för nuvarande ZimaOS.
ZimaOS 1.4.4 lade till en korrigering på produktnivå för NVMe från tredje part
I IceWhales versionsinformation för 1.4.4 står det uttryckligen att NVMe-diskar från tredjepartsenheter som visades som saknade i Lagring har korrigerats.
Se den officiella visningskorrigeringen för NVMe från tredje part.
ZimaOS 1.6.1 optimerade stora diskskåp från tredje part ytterligare
IceWhale optimerade senare visningslogiken för diskskåp när tredjepartsenheter har för många diskar. Det överlappar direkt med det gamla problemet med gränssnittsmappning och är ytterligare ett skäl till att nuvarande användare inte bör börja med att redigera en konfiguration från 2024.
Fastställ först om disken saknas i Linux eller bara i gränssnittet
- Om
lspci/lsblkkan inte se enheten, undersök maskinvara, styrenhetsläge, strömförsörjning, anslutning och drivrutinsstöd. - Om Linux ser enheten men Lagring inte gör det, samla in den aktuella ZimaOS-versionen samt information från användargränssnittet och lagringstjänsten.
Behandla ändringar i local-storage.conf som historiska eller avancerade
ZimaOS är nu ett mer oföränderligt appliance-operativsystem än många allmänna Linux-distributioner. Manuella ändringar under /etc kan vara versionskänsligt och kan ersättas av senare uppdateringar. Spara en kopia av originalfilen och följ aktuell supportvägledning om det moderna användargränssnittet fortfarande identifierar diskar fel.
En saknad diskruta är inte samma sak som en saknad disk
Källguiden handlade främst om hur diskar från tredje part ordnades och exponerades i ZimaOS användargränssnitt för lagring. Om lsblk och kärnloggarna ser en enhet, men sidan Lagring inte visar den korrekt, skiljer sig problemet från en styrenhet eller drivrutin som inte kan upptäcka disken alls.
Säkerhetskopiera local-storage.conf innan du redigerar den
Den historiska metoden ändrar en inbyggd konfigurationsfil i ZimaOS. Spara originalfilen först och anteckna den aktuella ZimaOS-versionen så att du kan återställa den om diskhyllan fungerar sämre efter ändringen.
Eftersom OTA-versioner sedan dess har ändrat hanteringen av diskar från tredje part kan ett gammalt manuellt ändrat värde också bli inaktuellt efter en uppdatering.
PCI-adresser kan ändras när maskinvarutopologin ändras
Om du flyttar ett NVMe-kort till en annan plats, ändrar en PCIe-bifurkeringsinställning eller uppdaterar plattformens inbyggda programvara kan det ändra hur enheter räknas upp. En hårdkodad adresslista hör därför till den maskinvarutopologin, inte till själva SSD-modellen.
Bevara källans oenighet om avgränsare
De officiella instruktionerna från 2024 beskriver kommaseparerade NVMe-adresser, medan en användare i communityn senare uppgav att mellanslag fungerade i deras system och att kommatecken inte gjorde det. Det finns inte tillräckligt med källunderlag för att universellt ersätta den officiella syntaxen med community-varianten.
I en aktuell version bör du uppdatera först och använda det exakta beteendet hos den aktuella tolken innan du ändrar fältet.
Stora diskhyllor från tredje part fick senare förbättringar på produktnivå
ZimaOS 1.6.1 förbättrade specifikt visningen av enheter från tredje part med ett större antal diskar. Användare med HBA-kort, kapslingar med flera fack eller fler än sex diskar bör därför återskapa problemet i den aktuella versionen innan de ändrar äldre inställningar för diskhyllans nummer.
Vanliga frågor om visning av diskar från tredje part
Betyder en disk som saknas i ZimaOS-diskhyllan att Linux inte kan se den?
Nej. Den ursprungliga guiden behandlade specifikt fall där maskinvaran fanns, men mappningen i användargränssnittet var felaktig.
Lade ZimaOS senare till officiella korrigeringar?
Ja. 1.4.4 åtgärdade att NVMe-diskar från tredje part visades som saknade, och 1.6.1 optimerade visningen av diskhyllor från tredje part.
Bör nuvarande användare ändra SataStartNumber eller NVME på måfå?
Nej. Uppdatera och bekräfta det aktuella fellagret först.
