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 Dieser Vorgang führte letztlich zu einer bestätigten Ursache von IceWhale. Nach dem Upgrade auf ZimaOS 1.5.3 wurde das NVMe-RAID-Array selbst zusammengebaut und eingebunden, aber hängte es sofort aus, weil die RAID-Datenbank fs_type = 'BTRFS'
in Großbuchstaben statt des vom Speichermanager erwarteten kleingeschriebenen Werts.
Dina von IceWhale stellte eine gezielte SQLite-Aktualisierung bereit. Der ursprüngliche Verfasser führte sie aus und bestätigte ausdrücklich, dass das RAID anschließend wieder normal eingebunden wurde. ZimaOS 1.5.4 führte das Problem beim automatischen Einhängen eines RAIDs mit großgeschriebenem BTRFS anschließend als offiziell behobenen Fehler auf. Aktuelle Nutzer sollten den SQL-Befehl daher als historische Wiederherstellungsanleitung für genau diesen Fehler betrachten, nicht als allgemeinen Reparaturbefehl für RAID.
Das RAID-Array war intakt, bevor die Speicherverwaltung es aushängte Das Journal zeigte, dass der Kernel das RAID automatisch erkannte und systemd/media/RAID-Storage-2 zimaos-local-storage und hängte es Sekunden später zwangsweise aus.
Der Quelldatenbankeintrag zeigte das RAID ebenfalls als status okhinzu. Dadurch war es weniger wahrscheinlich, dass ein ausgefallenes Mitglied oder ein zerstörtes Btrfs-Dateisystem vorlag.
Manueller fstab-Eintrag funktionierte nur als vorübergehende Umgehungslösung
Der Nutzer band das RAID manuell ein und fügte einen /etc/fstab Eintrag, aber die ZimaOS-Speicherverwaltung behandelte ihn nicht als maßgebliche Konfiguration. Beim Neustart setzte der local-storage-Dienst weiterhin seinen internen Datenbank-/Statuswert durch.
Deshalb sollte von der Appliance verwalteter Speicher normalerweise über die ZimaOS-Speicherebene repariert werden, statt ihn parallel manuell einzuhängen und zu verwalten.
Die Community identifizierte zimaos-local-storage korrekt als die zuständige Ebene
Bevor IceWhale die Ursache veröffentlichte, bemerkte gelbuilding die entscheidende Abfolge: Das Einhängen gelingt, dann zimaos-local-storage hängt es aus. Er riet richtigerweise dazu, Protokolle an IceWhale zu senden, anstatt die RAID-Metadaten wiederholt zu ändern.
Seine Vermutung einer strengeren Validierung war nicht die endgültige Diagnose; die spätere offizielle Diagnose war wesentlich spezifischer.
IceWhale fand den Fehler bei der Groß- und Kleinschreibung von fs_type
Dina schrieb, dass die Datenbank fs_type Der Wert war großgeschrieben, wodurch das Einhängen fehlschlug. IceWhale stellte Folgendes bereit:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"Der Nutzer antwortete später: „Das hat das Problem tatsächlich behoben.“
BTRFS in Kleinbuchstaben btrfs.ZimaOS 1.5.4 hat denselben Fehler beim automatischen Einhängen offiziell behoben
In den Versionshinweisen zu 1.5.4 wird ausdrücklich eine Behebung des Fehlers beim automatischen Einhängen aufgeführt, wenn RAID-Datenbankeinträge gespeichert wurden BTRFS in Großbuchstaben.
Siehe den offiziellen Fix für das Einbinden von RAID in ZimaOS 1.5.4.
Ein späterer Benutzer von Version 1.5.4 meldete weiterhin ein nicht eingebundenes RAID
Ein anderer Teilnehmer berichtete, dass auf seinem System mit Version 1.5.4 weiterhin ein Einbindungsproblem auftrat. Dina bat um eine aktuelle Datenträgerdiagnose und eine Beschreibung der Symptome, statt anzunehmen, dass es weiterhin der Fehler mit dem Dateisystemtyp in Großbuchstaben war.
Das ist die richtige Abgrenzung: Ähnliche Symptome können unterschiedliche Ursachen haben.
Führen Sie das alte SQL nicht auf einem aktuellen RAID aus, wenn die entsprechenden Belege fehlen
Die aktuelle ZimaOS-Version ist 1.7.1. Bevor Sie local-storage.db, überprüfen Sie, dass:
- das Array tatsächlich zusammengefügt wird;
- das Journal zeigt, dass der local-storage-Dienst das Array aushängt;
- die Datenbank tatsächlich den historischen Wert in Großbuchstaben enthält;
- Sie über eine aktuelle Sicherung und einen Diagnosebericht verfügen.
Wenn diese Bedingungen nicht übereinstimmen, kann eine Bearbeitung der Datenbank die Wiederherstellung eines anderen Speicherproblems erschweren.
Der offizielle Fix wurde gefunden, weil der Benutzer die richtigen Protokolle bereitstellte
IceWhale bat um /ZimaOS-HD/.log/casaos/local-storage.log nachdem die Community die Ebene der Speicherverwaltung identifiziert hatte. Dieses Protokoll ermöglichte es dem Team, von einer allgemeinen Theorie zur genauen Groß-/Kleinschreibungsabweichung zu gelangen.
Bei einem aktuellen Fehler beim Einbinden sollten dieselben Belege gesichert werden: Status des RAID-Zusammenfügens, Journalzeilen, Speicherstatus von ZimaOS und Diagnosedaten des lokalen Speichers, bevor Metadaten geändert werden.
Interne Metadaten vor jeder manuellen Datenbankbearbeitung sichern
Das SQL aus der Quelle war eine von IceWhale bereitgestellte einzeilige Korrektur für einen bekannten Fehler in Version 1.5.3. Falls erneut eine von Mitarbeitern angeleitete Datenbankbearbeitung erforderlich ist, sollte zuerst eine Sicherung der Datenbank bzw. des Status erstellt und anschließend nur die exakt zu korrigierende Bedingung angewendet werden.
Umfassende SQL-Aktualisierungen an RAID-Einträgen können die Ansicht der Speicherverwaltung vom tatsächlichen Array entkoppeln und einen behebbaren Einbindungsfehler in ein Problem der Metadatenwiederherstellung verwandeln.
Eine Neuinstallation ist nicht die erste Maßnahme bei einem intakten, aber nicht eingebundenen RAID
Da das Array selbst zusammengefügt wurde und die Daten intakt waren, wäre eine Neuinstallation oder Neuerstellung des RAIDs unnötig destruktiv gewesen. Wenn ein intaktes Array von Verwaltungsmetadaten abgewiesen wird, sollte die Verwaltungsebene repariert oder der Herstellersupport kontaktiert werden, bevor die Array-Geometrie verändert wird.
FAQ zum Einbinden von RAID
Wurde das RAID selbst in der Quelle zerstört?
Nein. Das Array wurde zusammengefügt und eingebunden, bevor die Speicherverwaltung von ZimaOS es wieder aushängte.
Was war die bestätigte Ursache?
Die RAID-Datenbank speicherte fs_type in Großbuchstaben BTRFS statt in Kleinbuchstaben btrfs.
Hat IceWhale das in einer Veröffentlichung behoben?
Ja. In ZimaOS 1.5.4 wird der behobene Fehler beim automatischen Einbinden von BTRFS mit Großbuchstaben ausdrücklich aufgeführt.
