Logbuch#opnsense#netzwerk#storage
Der Router bootete von einem USB-Stick
Von Niclas Hennrich · veröffentlicht · geschehen am
Etwas ist ausgefallen oder kaputtgegangen. Gehört zum Vorhaben Homelab Control Center.
- Bad-Block-Fehler auf dem Wurzeldateisystem
- 312
- Anbindung des Systemdatenträgers
- USB 2.0, 40 MB/s
- Tage am Stück bis zum Einfrieren
- 8
Nach der Rekonstruktion aus der Pi-hole-Datenbank stand der Verdacht: Der Router hängt. Zwei Tage lang blieb er eine Blackbox — der Monitoring-API-Benutzer sieht keine Logs, und im Inventar stand, dass es keinen Shell-Zugang gibt. Die Annahme stimmte nicht mehr. Als ich sie überprüfte, war die Diagnose in zwanzig Minuten erledigt.
Was in dem Gerät steckt. Ein N100-Board mit genau einem SATA-Port,
belegt von einer älteren Consumer-SSD, und einem freien M.2-Steckplatz
(NVMe, PCIe 3.0 x2). Und das Wurzeldateisystem? Auf da0 — einem 29-GB-
USB-Stick, der mit 40 MB/s am Bus hängt. USB 2.0. Darauf läuft ein Router,
der rund um die Uhr Logs und RRD-Daten schreibt. Die SSD hat keine
nutzbare Partitionstabelle mehr; ihr Wear-Leveling-Zähler sagt
„verschlissen", und im Lesetest fiel sie einmal vom Bus und kam nach neun
Sekunden zurück.
Die Zeitachse, jetzt mit Logs. Sechster September: zwei Boots im Abstand von acht Sekunden. Dreizehnter, 18:44: die letzte Logzeile überhaupt. 19:10: Netz tot. Vierzehnter, 18:13: Boot mit „/ is not clean — run fsck". 19:30: 312 Bad-Block-Fehler auf dem Wurzeldateisystem, danach wieder tot. Fünfzehnter: zwei Boots im Abstand von sieben Minuten. Das Muster der Doppel-Boots zieht sich durch Wochen: Der Router braucht mehrere Anläufe, bis er von dem Stick hochkommt.
Und eine Korrektur zum Eintrag vom Vortag: Dort stand, der fällige Reboot habe „zehn Tage" gelegen. Falsch — gebootet wurde am 6. September. Richtig ist, dass das Firmware-Update nie eingespielt wurde und der Reboot-Hinweis deshalb seit dem 3. September durchgehend stand. Die Eskalation, die ich dafür gebaut hatte, bleibt sinnvoll; ihre Begründung war ungenau.
Was ich getan habe — und was bewusst nicht. Konfiguration gesichert.
smartmontools installiert, ein Paket, zwei Megabyte, damit SMART
überhaupt sprechen kann. Sonst nichts: keine RAM-Disks aktiviert, kein
Firmware-Update eingespielt — beides schreibt auf den Stick, und der ist
nachweislich beschädigt. Ein Kopieren des laufenden Dateisystems verbietet
sich aus demselben Grund: Man nähme den Schaden mit.
Der Plan: NVMe in den freien Steckplatz, saubere Neuinstallation,
Konfiguration zurückspielen. Der Router war nie „instabil" im Sinne von
Software. Er stand auf einem Datenträger, der für Dauerschreiblast nicht
gebaut ist. smartctl gehört auf jedes Gerät mit eigenem Datenträger —
hier war es der Unterschied zwischen „Kabel locker" und „Speicher
verschlissen".