This source ultimately produced a confirmed IceWhale root cause. After upgrading to ZimaOS 1.5.3, the NVMe RAID array itself assembled and mounted, but zimaos-local-storage Deze bron leidde uiteindelijk tot een bevestigde hoofdoorzaak door IceWhale. Na de upgrade naar ZimaOS 1.5.3 werd de NVMe-RAID-array zelf samengesteld en gekoppeld, maar onmiddellijk ontkoppelde, omdat de RAID-database fs_type = 'BTRFS'
in hoofdletters in plaats van de door de opslagbeheerder verwachte waarde in kleine letters.
Dina van IceWhale verstrekte een gerichte SQLite-update. De oorspronkelijke poster voerde deze uit en bevestigde expliciet dat de RAID daarna normaal werd gekoppeld. ZimaOS 1.5.4 vermeldde vervolgens het probleem met automatisch koppelen van RAID's met BTRFS in hoofdletters als officieel opgelost. Huidige gebruikers moeten de SQL daarom beschouwen als historische herstelinstructie voor precies die fout, niet als een algemeen commando voor RAID-reparatie.
De RAID-array was gezond voordat de opslagbeheerder deze ontkoppelde Het journaal toonde dat de kernel de RAID automatisch detecteerde en dat systemd deze koppelde/media/RAID-Storage-2 zimaos-local-storage door het enkele seconden later geforceerd te ontkoppelen.
Het oorspronkelijke databaserecord toonde de RAID ook als status ok. Daardoor was het minder waarschijnlijk dat een lid was uitgevallen of dat een Btrfs-bestandssysteem was vernietigd.
Handmatige fstab werkte alleen als tijdelijke workaround
De gebruiker koppelde de RAID handmatig en voegde een /etc/fstab vermelding, maar het opslagbeheer van ZimaOS behandelde dat niet als de gezaghebbende configuratie. Bij het opnieuw opstarten bleef de local-storage-service zijn interne database/status afdwingen.
Daarom moet door een appliance beheerde opslag normaal gesproken via de ZimaOS-opslaglaag worden hersteld, in plaats van als een parallelle handmatige koppeling te worden onderhouden.
De community identificeerde zimaos-local-storage correct als de verantwoordelijke laag
Voordat IceWhale de hoofdoorzaak bekendmaakte, merkte gelbuilding de cruciale volgorde op: het koppelen slaagt en vervolgens zimaos-local-storage ontkoppelt het. Hij adviseerde terecht om logboeken naar IceWhale te sturen in plaats van de RAID-metagegevens herhaaldelijk te wijzigen.
Zijn speculatie over strengere validatie was niet de uiteindelijke diagnose; de latere officiële diagnose was veel specifieker.
IceWhale ontdekte de fout met hoofdlettergebruik van fs_type
Dina schreef dat de database fs_type de waarde stond in hoofdletters, waardoor het koppelen mislukte. IceWhale gaf het volgende:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"De gebruiker antwoordde later: “Dit heeft het probleem inderdaad opgelost.”
BTRFS in kleine letters btrfs.ZimaOS 1.5.4 heeft officieel dezelfde fout met automatisch koppelen opgelost
De releaseopmerkingen van versie 1.5.4 vermelden expliciet een oplossing voor het mislukken van automatisch koppelen wanneer RAID-databasegegevens zijn opgeslagen BTRFS in hoofdletters.
Zie de officiële oplossing voor het koppelen van RAID in ZimaOS 1.5.4.
Een latere gebruiker van versie 1.5.4 meldde nog steeds een niet-gekoppelde RAID
Een andere deelnemer meldde dat er op hun systeem met versie 1.5.4 nog steeds een koppelingsprobleem optrad. Dina vroeg om een nieuwe schijfdiagnose en een beschrijving van de symptomen, in plaats van aan te nemen dat het nog steeds om de bug met uppercase fs_type ging.
Dat is de juiste afbakening: vergelijkbare symptomen kunnen verschillende oorzaken hebben.
Voer de oude SQL niet uit op een actuele RAID zonder overeenkomend bewijs
De huidige versie van ZimaOS is 1.7.1. Voordat je local-storage.db, controleer dan of:
- de array daadwerkelijk wordt samengesteld;
- het logboek laat zien dat de local-storage-service de koppeling ongedaan maakt;
- de database daadwerkelijk de historische waarde met hoofdletters bevat;
- je een actuele back-up en een diagnostisch rapport hebt.
Als niet aan die voorwaarden wordt voldaan, kan het bewerken van de database het herstel van een ander opslagprobleem bemoeilijken.
De officiële oplossing werd gevonden omdat de gebruiker de juiste logs aanleverde
IceWhale vroeg om /ZimaOS-HD/.log/casaos/local-storage.log nadat de community de opslagbeheerlaag had geïdentificeerd. Dankzij dat log kon het team van een brede theorie overstappen naar de exacte fout met hoofdlettergebruik.
Bewaar bij een actuele koppelingsfout hetzelfde bewijspatroon: de RAID-samenstellingsstatus, logboekregels, de opslagstatus van ZimaOS en diagnoses van de lokale opslag voordat je metadata wijzigt.
Maak een back-up van interne metadata voordat je een handmatige databasebewerking uitvoert
De bron-SQL was een door IceWhale verstrekte correctie van één regel voor een bekende fout in versie 1.5.3. Als opnieuw een door medewerkers begeleide databasebewerking nodig is, maak dan eerst een back-up van de database/status en pas alleen de exacte te corrigeren voorwaarde toe.
Algemene SQL-updates voor RAID-records kunnen de weergave van de opslagbeheerder loskoppelen van de echte array en een herstelbare koppelingsbug veranderen in een probleem met metadataherstel.
Een herinstallatie is niet de eerste stap bij een gezonde maar niet gekoppelde RAID
Omdat de array zelf werd samengesteld en de gegevens intact waren, zou het opnieuw installeren of opnieuw aanmaken van de RAID onnodig destructief zijn geweest. Wanneer een gezonde array door beheermetadata wordt afgewezen, repareer dan de beheerlaag of neem contact op met de ondersteuning van de leverancier voordat je de arrayconfiguratie wijzigt.
Veelgestelde vragen over RAID-koppelen
Was de RAID zelf in de bron beschadigd?
Nee. De array werd samengesteld en gekoppeld voordat ZimaOS Storage Management de koppeling ongedaan maakte.
Wat was de bevestigde hoofdoorzaak?
De RAID-database sloeg fs_type als hoofdletters BTRFS in plaats van kleine letters btrfs.
Heeft IceWhale dit in een release opgelost?
Ja. In ZimaOS 1.5.4 wordt expliciet vermeld dat de bug met automatisch koppelen van uppercase BTRFS is opgelost.
