Wenn beide ZimaOS-Boot-Slots ausfallen und die Konsole Fehler beim Einhängen des Overlays, beim Lesen des Superblocks oder NVMe-I/O-Fehler meldet, sollten Sie nicht mit dem Neuaufbau des Speicherpools beginnen. Stellen Sie zuerst fest, ob der Fehler auf dem Boot-Laufwerk oder auf den separaten Datenlaufwerken liegt.
In diesem Fall aus dem Juni 2026 zeigten schreibgeschützte Diagnosen wiederholte Medienfehler auf der Boot-NVMe, während der große Btrfs-Datenpool auf separaten Laufwerken lag. Der Benutzer ersetzte das Boot-Laufwerk, installierte ZimaOS neu und bestätigte später, dass der Datenpool noch vorhanden war.
Boot-Laufwerk und Datenpool zuerst getrennt betrachten
Die Ausgabe der Rettungsshell im Thread zeigte eine etwa 119 GB große NVMe mit ZimaOS-Boot- und Datenpartitionen sowie einen separaten Btrfs-Pool mit mehreren Laufwerken. Diese Unterscheidung änderte den Wiederherstellungsplan: Der Ausfall der Boot-NVMe bedeutete nicht automatisch, dass der Speicherpool ausgefallen war.
Beginnen Sie mit schreibgeschützten Befehlen:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineNotieren Sie die exakten Gerätenamen, bevor Sie einen Befehl ausführen, der auf ein Laufwerk oder eine Partition zugreift.
Kernel-Protokolle auf echte I/O-Fehler prüfen
Der Ausgangsfall enthielt wiederholte Meldungen wie critical medium error, Buffer I/O error, EXT4-Einhängefehler und NVMe-Fehler für das Boot-Laufwerk. Diese Meldungen sind deutlich stärkere Hinweise auf einen Speicherausfall als ein allgemeiner Panic-Fehler auf dem Boot-Bildschirm.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Wenn die Fehler durchgehend auf die Boot-NVMe verweisen, während die Datenlaufwerke keine Fehler melden, sollten Sie die Untersuchung auf den Boot-Pfad konzentrieren.
Ein SMART-Ergebnis „PASSED“ schließt Medienfehler nicht aus
Im Thread zeigte die SMART-Zusammenfassung der NVMe weiterhin PASSED an. Die detaillierten Zähler wiesen jedoch 76 Medien-/Datenintegritätsfehler aus, und der Kernel protokollierte bereits fehlgeschlagene Lesevorgänge. Auch die schreibgeschützte Dateisystemprüfung wurde wegen nicht lesbarer Blöcke abgebrochen.
Verwenden Sie detaillierte Zustandsdaten wie smartctl -x /dev/nvmeXn1 oder nvme smart-log /dev/nvmeXn1, nachdem Sie den korrekten Gerätenamen bestätigt haben. Behandeln Sie das einzelne allgemeine Zustandswort nicht als vollständige Diagnose.
Zuerst schreibgeschützte Dateisystemprüfungen verwenden
Die Community verwendete e2fsck -fn für die betroffene EXT4-Overlay-Partition, damit das Dateisystem ohne Reparaturschreibvorgänge untersucht werden konnte. Selbst diese schreibgeschützte Prüfung stieß auf nicht lesbare Blöcke, was die Diagnose eines Hardwarefehlers weiter erhärtete.
Führen Sie niemals fsck im Schreibmodus auf einem eingehängten Dateisystem aus und raten Sie keine Partitionsnamen. Wenn die Boot-SSD physisch ausfällt, können wiederholte Schreibversuche die Wiederherstellung erschweren.
Warum sowohl Slot A als auch Slot B ausfallen können
ZimaOS verwendet A/B-System-Slots zur Wiederherstellung, wie im ZimaOS-Leitfaden zur Systemwiederherstellung beschrieben. Beide Boot-Optionen hängen jedoch weiterhin von funktionsfähigen gemeinsam genutzten Speicherkomponenten auf dem Boot-Laufwerk ab. Ein fehlerhaftes Overlay oder eine ausfallende Boot-NVMe kann daher verhindern, dass beide Slots den Startvorgang abschließen.
Wann ein Austausch der sicherere Weg ist
Nachdem der Ausgangsfall Kernel-Medienfehler, detaillierte SMART-Medienfehlerzähler und nicht lesbare Dateisystemblöcke auf der Boot-NVMe gezeigt hatte, empfahl die Community, die SSD als nicht vertrauenswürdig zu behandeln, statt sie im eingebauten Zustand reparieren zu wollen. Der Benutzer ersetzte sie und installierte ZimaOS erfolgreich neu.
Halten Sie während der Neuinstallation die Datenlaufwerke eindeutig identifiziert und vermeiden Sie es, einen vorhandenen Pool zu initialisieren oder neu zu erstellen. Der Leitfaden zur Fehlerbehebung bei der ZimaOS-Installation unterstützt Sie beim Boot-Installationsvorgang. Der Leitfaden zur Speicherwiederherstellung nach der Neuinstallation bekräftigt außerdem die wichtigste Regel: Erstellen Sie keinen Pool neu, der bereits Ihre Daten enthält.
Zusammenfassung
In diesem Fall wurde der Kernel-Panic durch einen Ausfall der Boot-NVMe verursacht und war kein Beweis dafür, dass der separate Datenpool zerstört worden war. Führen Sie die Diagnose schreibgeschützt durch, bestätigen Sie, auf welchem Gerät die I/O-Fehler auftreten, und lassen Sie die Datenlaufwerke unangetastet. Der ursprüngliche Benutzer ersetzte das ausgefallene Boot-Laufwerk, installierte ZimaOS neu und bestätigte, dass der vorhandene Datenpool erhalten geblieben war.
