Bei der Bundesbank Würzburg trat ebendieser Fehler auf.
Der Fehler besagt, dass Grub zwar ein Laufwerk erkennt, aber das Dateisystem nicht mounten kann.
Üblicherweise haben beim TS400 die Disks, CF oder SSD, drei Partitionen: P1 = Boot-Partition, P2 = Swap-Partition und P5 = /var
Teile der Software liegen seit etwa V1.11.4450 unter /usr/ts400 (= P1) und könnten auch beschädigt sein. Der ganze Rest liegt jedoch unter /var (= P5) und ist höchstwahrscheinlich nicht betroffen. Zuvor lag auch alle Software unter /var. Die Chancen stehen also gut, dass nichts verloren ist.
Das Booten eines Live-Systems ist nicht immar ganz ohne Tücken. Im vorliegenden Fall bootete ich ab dem Lenny-Installer (USB-Stick) im Rescue-Modus. Der Epiphan KVM2USB konnte daraufhin nicht als Tastatur benutzt werden, also musste eine normale PC-Tastatur her. Überhaupt müsste spätestens jetzt klar sein, dass sowohl zur Diagnose als auch zur Fehlerbehebung die direkte Bedienung des Rechners per Monitor/Tastatur notwendig ist.
einmal gebootet liess sich die Partition 1 tatsächlich nicht mounten. Die Partition 5 war problemlos zu mounten.
Ein 'fsck2.ext3 /dev/hda1 -y' behob alle Fehler im Dateisystem und das TS400 bootete danach auch wieder. Allerdings mit 'security violation', was auf veränderte Daten hindeutet.
per '/usr/ts400/bin/unarch.php check errorsonly' war bald klar, dass einige Dateien vom Paket smbfs schadhaft waren und auch ein Kernel-Treiber für ein RAID sich verändert hatte. Per 'dpkg -i /var/cache/apt/archive/smbfs*' und 'dpkg -i /var/cache/apt/archive/linux-image*' waren diese Probleme behoben. Es besteht aber immer noch die Möglichkeit, dass auch andere nicht überprüfte Dateien noch beschädigt waren. Eigentlich hätte dem System ein 'dpkg -i /var/cache/apt/archive/*' gut getan, mit dem alle Programme neu installiert worden wären. Das war mein Versäumnis.
Anschliessend wurde das System normal auf die letzte stabile TS400-Version gehoben und lief danach anstandslos. Ein anschliessendes '/usr/ts400/bin/unarch.php check errorsonly' zeigte keine Probleme mehr.
Wäre der Schaden grösser gewesen, hätte das System neu aufgesetzt werden müssen, was beim Kunden nicht machbar gewesen wäre. Also hätte
ein Ersatzgerät eingesetzt werden müssen. Da hätte die TS400-Software bereits installiert sein müssen. Seit der Version 1.11 (und ein paar der letzten V1.10)
hätte es gereicht, die Datenbank /var/alertroot/config/io.db zu übertragen. Früher hätte Fehlendes aus den Unterverzeichnissen von /var/alertroot
ergänzt werden müssen, und fast immer dabei war /var/alertroot/config/sysconfig.php. Es schadet noch heute nicht, das ganze Verzeichnis /var/alertroot zu
übernehmen, mit Ausnahme von /var/alertroot/arch.
Seit es dieses Verzeichnis gibt, liegen da grosse Teile der Software auf das Gerät verschlüsselt.
Man würde also die Software vom Ersatzgerät tendenziell 'abschiessen'.
Auch nicht schlecht ist es, die Datei /var/lib/misc/dnsmasq.leases zu übernehmen.
Damit bleiben die Leases der Wago-Knoten erhalten.
vor einem Reboot immer ...
... per '/usr/ts400/bin/unarch.php check errorsonly' überprüfen, ob die Software korrekt registriert ist, und es ansonsten per '/usr/ts400/bin/autoarch.php pwd=<passwort>'
korrigieren.
Danach unbedingt per Reboot überprüfen, ob das System wieder startet.