ZimaOS-RAID-Fehlerbehebung auf Nicht-ZimaCube-Hardware

Wenn ZimaOS deine Laufwerke erkennt, der Bildschirm zur RAID-Erstellung sie jedoch den falschen Laufwerksschächten zuordnet, auswählbare Steckplätze leer lässt oder nur einige Datenträger anzeigt, trenne zunächst ein aktuelles RAID-Zustandsproblem von dem alten, in diesem Thread dokumentierten Zuordnungsproblem für Nicht-ZimaCube-Datenträger. Seite 2 spiegelt größtenteils das Verhalten von ZimaOS 1.2.x und frühen 1.3.x-Versionen auf DIY-Hardware wider.

Die aktuelle RAID-Fehlerbehebung in ZimaOS beginnt mit der Laufwerksanzahl, dem Zustand der Datenträger, der individuellen Formatierung, einem leeren Einhängepunkt und einem Neustart. Erst nach diesen Prüfungen solltest du alte Workarounds zur Laufwerksschacht-Zuordnung in Betracht ziehen – und nur, wenn du denselben Zuordnungsfehler in deiner aktuellen Version reproduzieren kannst.

So sah der alte Fehler bei der Laufwerkszuordnung aus

Mehrere Nutzer von Nicht-ZimaCube-Hardware berichteten, dass physisch angeschlossene Laufwerke in unerwarteten virtuellen Positionen erschienen. Die Speicherseite konnte Datenträger in den Laufwerksschächten 4, 5 und 6 anzeigen, während der RAID-Dialog Datenträger in früheren Positionen erwartete. Dadurch blieb die Schaltfläche „Weiter“ deaktiviert oder ein Laufwerk wurde aus der Auswahl ausgeblendet.

Ältere ZimaOS-Speicheransicht mit Nicht-ZimaCube-Datenträgern in unerwarteten Laufwerksschächten — Ein älterer ZimaOS-Build ordnete Datenträger von DIY-Hardware unerwarteten Laufwerksschächten zu.

Älterer ZimaOS-Speichermanager mit Datenträgern in den Laufwerksschächten 4, 5 und 6 — Die Speicheroberfläche konnte Datenträger erkennen, während das RAID-Auswahlmodell ihre Verwendung weiterhin erschwerte.

Erkennung und RAID-Eignung waren zwei verschiedene Ebenen

Älterer ZimaOS-Bildschirm zur RAID-Erstellung auf LincStation-Hardware mit nicht verfügbaren Laufwerksschächten — Ein DIY-System konnte Speicher auflisten, während der RAID-Auswahlworkflow weiterhin unvollständig blieb.

Diese Unterscheidung ist auch heute noch nützlich. Wenn ein Datenträger in lsblk beweist, dass der Kernel ein Blockgerät erkennt. Wenn es in „Dateien“ oder im Speichermanager angezeigt wird, beweist das, dass eine weitere Ebene es erkennt. Für RAID auswählbar zu sein, fügt noch eine weitere Eignungs- und UI-Ebene hinzu.

Wenn eine Ebene fehlschlägt, erfasse, an welcher Stelle der Datenträger verschwindet, statt ihn sofort zu löschen. Prüfe den Dateisystemstatus, vorhandene RAID-Metadaten, den Einhängezustand und ob die aktuelle Benutzeroberfläche den Datenträger für ein neues Array als verfügbar betrachtet.

Älteres ZimaOS-Panel „Neue Festplatte“ aus einem Fall zur RAID-Fehlerbehebung auf Nicht-ZimaCube-Hardware — Die Speicherschicht konnte ein Laufwerk erkennen, selbst wenn der RAID-Workflow es nicht wie erwartet zugeordnet hat.

Älterer ZimaOS-RAID0-Bildschirm mit nur einem auswählbaren Laufwerksschacht auf DIY-Hardware — Ein weiterer Screenshot zeigt dieselbe Abweichung auf der Seite zur RAID-Erstellung: Der erkannte Speicher wurde nicht in die erwarteten auswählbaren Laufwerksschächte übertragen.

Aktuelle RAID-Prüfungen vor dem Bearbeiten der Systemkonfiguration durchführen

Die aktuelle offizielle Anleitung zur RAID-Fehlerbehebung empfiehlt, mindestens zwei Laufwerke zu überprüfen, den Zustand der Datenträger zu kontrollieren, sicherzustellen, dass jeder Datenträger erfolgreich formatiert werden kann, zu bestätigen, dass der vorgesehene RAID-Einhängepunkt leer ist, und vor einem erneuten Erstellungsversuch neu zu starten.

Aktuelle Checkliste zur Fehlerbehebung bei ZimaOS-RAID sollte auch bei DIY-Hardware dein erster Ansatz sein, da sie destruktive Annahmen vermeidet.

SataStartNumber war ein versionsspezifischer Community-Workaround

Im alten Thread bestätigte ein Mitglied des IceWhale-Teams, dass die frühe ZimaOS-Benutzeroberflächenlogik stark an das Layout der ZimaCube-Steckplätze gebunden war. Den Benutzern wurde empfohlen, die Platzierung der Festplatten-Controller mit lsblk -o hctl und bei bestimmten DIY-Systemen die Controller-Platzierung der Festplatten anpassen: SataStartNumber in /etc/casaos/local-storage.conf.

Einige Benutzer bestätigten, dass dadurch die Zuordnung der virtuellen Schächte korrigiert wurde; andere berichteten später, dass neuere ZimaOS-Versionen ihr Setup ohne Beibehaltung desselben Workarounds behoben. Daher handelt es sich bei der Änderung um eine historische Kompatibilitätstechnik und nicht um eine aktuelle allgemeingültige Voraussetzung.

Wenden Sie keine alte SataStartNumber Wert von einem anderen Mainboard. Die Controller-Topologie unterscheidet sich je nach System, und das aktuelle ZimaOS verwendet möglicherweise nicht mehr dieselben Annahmen.

Die Screenshots zeigen, warum Versionsgrenzen wichtig sind

Älterer ZimaOS-Speichermanager, nachdem die Zuordnung der Festplattenschächte korrigiert worden war — Ein Benutzer zeigte später Festplatten, die nach Behebung des Zuordnungsproblems die erwarteten frühen Schachtpositionen belegten.

ZimaOS-Versionsbildschirm mit einem frühen 1.3.1-Beta-Build — Teile des Threads wurden auf frühen 1.3.x-Builds getestet, die deutlich älter als die aktuelle 1.7.x-Oberfläche sind.

ZimaOS 1.7.1 enthält außerdem eine Fehlerbehebung für die ungenaue Anzeige des RAID-Status in bestimmten Szenarien. Das beweist nicht, dass jedes DIY-Schacht-Zuordnungsproblem gelöst ist, ist aber ein weiterer Grund, das Problem auf einem aktuellen Build zu reproduzieren, bevor eine Konfigurationsänderung aus dem Jahr 2024 angewendet wird.

Die Shell-Workaround für fünf Festplatten nicht in ein allgemeines Rezept umwandeln

Ein späterer Teilnehmer hatte fünf NVMe-Geräte mit jeweils 8 TB. Die Benutzeroberfläche zeigte für die RAID-Erstellung nur vier an, obwohl das fünfte Gerät an anderer Stelle sichtbar war, und der Benutzer erweiterte RAID5 schließlich manuell mit mdadm.

Ältere ZimaOS-Speicheransicht, die fünf NVMe-Geräte erkannte, von denen eines eine ungewöhnliche Steckplatznummer hatte — Die fünfte NVMe war für das System sichtbar, wurde aber anders zugeordnet als die ersten vier.

Ältere ZimaOS-Festplattenliste mit fünf Linux-RAID-Mitgliedsgeräten — Die Festplattenliste und die RAID-Erstellungsoberfläche stellten nicht dieselbe nutzbare Auswahl bereit.

Älterer ZimaOS-RAID5-Auswahlbildschirm aus dem Fehlerbehebungsfall mit fünf NVMe-Laufwerken — Der RAID5-Ablauf war Teil der Belege für den Vergleich, welche Festplatten sichtbar beziehungsweise auswählbar waren.

Älterer ZimaOS-RAID5-Erstellungsbildschirm, der nur vier auswählbare NVMe-Laufwerke zeigte — Das fünfte Gerät fehlte im normalen RAID5-Auswahlschritt.

Älterer ZimaOS-RAID5-Status, während eine fünfte Festplatte integriert wurde — Der Benutzer erweiterte das Array schließlich über die Shell, aber dieses Verfahren wird hier nicht als allgemeine Empfehlung wiedergegeben.

Das Stoppen, erneute Zusammenbauen oder Erweitern eines Arrays mit Befehlen auf niedriger Ebene kann zu Datenverlust führen, wenn die Geräteliste oder die Annahmen zu den Metadaten falsch sind. Sichern Sie bei einem aktuellen System, das die Festplatten erkennt, sie aber nicht in der RAID-Benutzeroberfläche verwenden kann, wichtige Daten und eskalieren Sie den Fall mit Versionsangabe, lsblk Ausgabe, Controller-Topologie, Screenshots und der aktuelle Zustand des Arrays statt der alten Shell-Befehlsfolge.