Denna källa ledde slutligen till en bekräftad grundorsak från IceWhale. Efter uppgradering till ZimaOS 1.5.3 monterades NVMe RAID-arrayen och sattes samman korrekt, men zimaos-local-storage avmonterade den omedelbart eftersom RAID-databasen innehöll fs_type = 'BTRFS' med versaler i stället för det värde med gemener som lagringshanteraren förväntade sig.
Dina från IceWhale tillhandahöll en riktad SQLite-uppdatering. Den ursprungliga skribenten körde den och bekräftade uttryckligen att RAID-enheten därefter monterades normalt. ZimaOS 1.5.4 listade sedan problemet med automatisk montering av RAID-enheter med BTRFS med versaler som en officiellt åtgärdad punkt. Nuvarande användare bör därför betrakta SQL-kommandot som historisk återställningsväg för just det felet, inte som ett allmänt kommando för RAID-reparation.
RAID-arrayen var felfri innan lagringshanteraren avmonterade den
Journalen visade att kärnan identifierade RAID-enheten automatiskt och att systemd monterade /media/RAID-Storage-2, och sedan zimaos-local-storage tvångsavmonterade den några sekunder senare.
Källans databaspost visade också RAID-enheten som status ok. Det gjorde att ett trasigt medlemsdisksystem eller ett förstört Btrfs-filsystem blev mindre sannolikt.
Manuell fstab fungerade endast som en tillfällig lösning
Användaren monterade RAID-enheten manuellt och lade till en /etc/fstab posten, men ZimaOS lagringshantering behandlade inte detta som den auktoritativa konfigurationen. Vid omstart tillämpade den lokala lagringstjänsten fortfarande sin interna databas sitt interna tillstånd.
Detta är anledningen till att lagring som hanteras av en appliance normalt bör repareras via ZimaOS lagringslager i stället för att underhållas som en parallell manuell montering.
Communityn identifierade korrekt zimaos-local-storage som det ansvariga lagret
Innan IceWhale publicerade grundorsaken lade gelbuilding märke till den viktiga sekvensen: monteringen lyckas, sedan zimaos-local-storage avmonterar den. Han rekommenderade korrekt att skicka loggar till IceWhale i stället för att upprepade gånger ändra RAID-metadata.
Hans spekulation om striktare validering var inte den slutliga diagnosen; den senare officiella diagnosen var mycket mer specifik.
IceWhale hittade felet med versaler i fs_type
Dina skrev att databasen fs_type värdet skrevs med versaler, vilket gjorde att monteringen misslyckades. IceWhale tillhandahöll:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"Användaren svarade senare: ”Detta löste faktiskt problemet.”
BTRFS med gemener btrfs.ZimaOS 1.5.4 åtgärdade officiellt samma problem med automatisk montering
Versionskommentarerna för 1.5.4 listar uttryckligen en korrigering av fel vid automatisk montering när RAID-databasposter lagrade BTRFS med versaler.
Se den officiella korrigeringen av RAID-montering i ZimaOS 1.5.4.
En senare 1.5.4-användare rapporterade fortfarande att RAID inte var monterat
En annan deltagare sa att ett monteringsproblem fortfarande inträffade på deras 1.5.4-system. Dina bad om färsk disdiagnostik och en symtombeskrivning i stället för att anta att det fortfarande var felet med fs_type med versaler.
Det är den korrekta avgränsningen: liknande symtom kan ha olika orsaker.
Kör inte den gamla SQL-koden på ett aktuellt RAID utan motsvarande bevis
Den aktuella versionen av ZimaOS är 1.7.1. Innan du rör local-storage.db, kontrollera att:
- arrayen faktiskt monteras;
- journalen visar att local-storage-tjänsten avmonterar den;
- databasen verkligen innehåller det historiska värdet med versaler;
- du har en aktuell säkerhetskopia och diagnostikrapport.
Om dessa villkor inte stämmer kan en redigering av databasen göra ett annat lagringsproblem svårare att återställa.
Den officiella korrigeringen hittades eftersom användaren skickade rätt loggar
IceWhale bad om /ZimaOS-HD/.log/casaos/local-storage.log efter att communityn identifierat lagringshanteringslagret. Den loggen gjorde det möjligt för teamet att gå från en bred teori till det exakta felet med versaler.
Vid ett aktuellt monteringsfel ska du bevara samma bevismönster: status för RAID-montering, journalrader, ZimaOS lagringsstatus och diagnostik för lokal lagring innan du ändrar metadata.
Säkerhetskopiera interna metadata innan du redigerar databasen manuellt
Källans SQL var en korrigering på en rad från IceWhale för ett känt fel i 1.5.3. Om en databasredigering som vägleds av personal skulle behövas igen ska du först säkerhetskopiera databasen/tillståndet och endast tillämpa den exakta korrigeringen av villkoret.
Breda SQL-uppdateringar av RAID-poster kan koppla bort lagringshanteringens vy från den verkliga arrayen och omvandla ett reparerbart monteringsfel till ett metadataåterställningsproblem.
En ominstallation är inte den första åtgärden för ett felfritt men omonterat RAID
Eftersom själva arrayen monterades och datan var intakt hade ominstallation eller återskapande av RAID varit onödigt destruktivt. När en felfri array avvisas på grund av hanteringsmetadata bör du reparera hanteringslagret eller kontakta leverantörens support innan du ändrar arrayens struktur.
Vanliga frågor om RAID-montering
Förstördes själva RAID-arrayen i källan?
Nej. Arrayen monterades och monterades innan ZimaOS lagringshantering avmonterade den.
Vad var den bekräftade grundorsaken?
RAID-databasen lagrade fs_type med versaler BTRFS i stället för gemener btrfs.
Åtgärdade IceWhale detta i en version?
Ja. ZimaOS 1.5.4 anger uttryckligen att felet med automatisk montering av BTRFS med versaler är åtgärdat.
