Gemenskapslösning

Felsökning av skapande av ZimaOS-RAID på hårdvara som inte är ZimaCube

Page 2 of a long RAID troubleshooting thread documented old ZimaOS 1.2.x/1.3.x disk-slot mapping problems on non-ZimaCube systems, community config edits, and later reports that newer builds resolved some cases.

Om ZimaOS ser dina diskar men skärmen för RAID-skapande tilldelar dem fel diskplatser, lämnar valbara platser tomma eller bara visar vissa diskar, bör du först skilja ett aktuellt RAID-hälsoproblem från det gamla problemet med diskmappning på hårdvara som inte tillhör ZimaCube och som dokumenteras i den här tråden. Sida 2 återspeglar i stor utsträckning beteendet i ZimaOS 1.2.x och tidiga 1.3.x på DIY-hårdvara.

Den aktuella RAID-felsökningen i ZimaOS börjar med antal enheter, diskhälsa, individuell formatering, en tom monteringspunkt och en omstart. Först efter dessa kontroller bör du överväga gamla lösningar för platsmappning – och endast om du kan återskapa samma mappningsfel i din nuvarande version.

Så såg den gamla diskmappningsbuggen ut

Flera användare med hårdvara som inte tillhör ZimaCube rapporterade att fysiskt anslutna diskar visades på oväntade virtuella platser. Lagringssidan kunde visa diskar på platserna 4, 5 och 6 medan RAID-dialogrutan förväntade sig diskar på tidigare platser, vilket gjorde Nästa-knappen otillgänglig eller dolde en disk från urvalet.

Äldre ZimaOS-lagringsvy som visar diskar som inte tillhör ZimaCube tilldelade oväntade diskplatser
En äldre ZimaOS-version mappade diskar i DIY-hårdvara till oväntade diskplatser.
Äldre ZimaOS Lagringshanterare med diskar visade på platserna 4, 5 och 6
Lagringsgränssnittet kunde känna igen diskar medan modellen för RAID-val fortfarande gjorde dem svåra att använda.

Identifiering och RAID-behörighet var två olika lager

Äldre ZimaOS-skärm för RAID-skapande på LincStation-hårdvara med otillgängliga diskplatser
Ett DIY-system kunde lista lagring men ändå lämna RAID-valarbetsflödet ofullständigt.

Den här åtskillnaden är fortfarande användbar i dag. Att se en disk i lsblk bevisar att kärnan ser en blockenhet. Om den visas i Filer eller Lagringshanteraren bevisar det att ytterligare ett lager känner igen den. Att den kan väljas för RAID innebär ännu ett lager av behörighet och gränssnitt.

Om ett lager fallerar bör du dokumentera var disken försvinner i stället för att omedelbart radera den. Kontrollera filsystemets tillstånd, befintliga RAID-metadata, monteringsstatus och om det aktuella gränssnittet anser att disken är tillgänglig för en ny array.

Äldre ZimaOS-panelen för ny hårddisk från ett RAID-felsökningsfall som inte gällde ZimaCube
Lagringslagret kunde upptäcka en disk även när RAID-arbetsflödet inte mappade den som förväntat.
Äldre ZimaOS RAID0-skärm där endast en diskplats kunde väljas på DIY-hårdvara
En annan skärmbild visar samma avvikelse från RAID-skapandets sida: detekterad lagring översattes inte till de förväntade valbara diskplatserna.

Kör de aktuella RAID-kontrollerna innan du redigerar systemkonfigurationen

Den aktuella officiella RAID-felsökningsguiden rekommenderar att du kontrollerar minst två enheter, granskar diskarnas hälsa, bekräftar att varje disk kan formateras utan problem, säkerställer att den avsedda RAID-monteringspunkten är tom och startar om innan du försöker skapa RAID igen.

Aktuell felsökningschecklista för ZimaOS RAID bör vara ditt första steg även med DIY-hårdvara, eftersom den undviker destruktiva antaganden.

SataStartNumber var en versionsspecifik lösning från communityn

I den gamla tråden bekräftade en medlem av IceWhale-teamet att den tidiga ZimaOS-logiken i gränssnittet var starkt knuten till ZimaCubes facklayout. Användare uppmanades att kontrollera diskarnas placering på styrenheterna med lsblk -o hctl och justera, för vissa DIY-system, SataStartNumber i /etc/casaos/local-storage.conf.

Vissa användare bekräftade att detta korrigerade den virtuella fackmappningen, medan andra senare rapporterade att nyare ZimaOS-versioner löste deras konfiguration utan att samma lösning behövde behållas. Det gör ändringen till en historisk kompatibilitetsteknik, inte ett universellt aktuellt krav.

Tillämpa inte en gammal SataStartNumber värde från ett annat moderkort. Styrenhetstopologin skiljer sig mellan olika system, och aktuella ZimaOS kanske inte längre använder samma antaganden.

Skärmbilderna visar varför versionsgränser är viktiga

Äldre ZimaOS Storage Manager efter att diskmappningen för facken hade korrigerats
En användare visade senare diskar som låg på de förväntade tidiga fackpositionerna efter att mappningsproblemet hade åtgärdats.
ZimaOS-versionsskärm som visar en tidig betaversion av 1.3.1
Delar av tråden testades på tidiga 1.3.x-versioner, som är betydligt äldre än det aktuella 1.7.x-gränssnittet.

ZimaOS 1.7.1 innehåller också en korrigering för felaktig visning av RAID-status i vissa scenarier. Det bevisar inte att alla fall av mappning av DIY-fack är lösta, men det är ytterligare ett skäl att återskapa problemet på en aktuell version innan du följer en konfigurationsändring från 2024.

Gör inte skalarbetslösningen för fem diskar till ett generellt recept

En senare deltagare hade fem NVMe-enheter på 8 TB. Gränssnittet visade endast fyra för RAID-skapande, trots att den femte enheten var synlig på annat håll, och användaren utökade till slut RAID5 manuellt med mdadm.

Äldre ZimaOS-lagringsvy som upptäcker fem NVMe-enheter, där en har tilldelats ett ovanligt platsnummer
Den femte NVMe-enheten var synlig för systemet men mappades annorlunda än de fyra första.
Äldre ZimaOS-disklista som visar fem Linux RAID-medlemsenheter
Disklistan och gränssnittet för att skapa RAID visade inte samma uppsättning användbara enheter.
Äldre ZimaOS-skärm för val av RAID5 från felsökningsfallet med fem NVMe-enheter
RAID5-arbetsflödet var en del av underlaget som användes för att jämföra vilka diskar som var synliga respektive valbara.
Äldre ZimaOS-skärm för skapande av RAID5 som endast visar fyra valbara NVMe-enheter
Den femte enheten saknades i det normala steget för val av RAID5.
Äldre ZimaOS RAID5-status medan en femte disk höll på att läggas till
Användaren utökade till slut arrayen från skalet, men den proceduren återges inte här som en generell rekommendation.

Att stoppa, återskapa eller utöka en array med lågnivåkommandon kan orsaka dataförlust om enhetslistan eller antagandena om metadata är felaktiga. För ett aktuellt system som identifierar diskar men inte kan använda dem i RAID-gränssnittet bör du säkerhetskopiera viktiga data och eskalera ärendet med version, lsblk utdata, styrenhetstopologi, skärmbilder och befintligt arraytillstånd i stället för att kopiera den gamla skalordningen.