R/W Fehler beim FW Update und wie ich damit klar gekommen bin - Austausch des DOM

[EPILOG]

Ein neues FW Update ist frisch raus, ich bin mutig und führe es aus, schließlich gab es zuletzt keine Probleme mit neuer Firmware.

Erste Amtshandlung ist es die Community über das neue Update und die ersten Resultate zu informieren:

Auf zwei Geräten geht es gut, auf meiner TS-251+ jedoch nicht, ich nenne sie (warum weiblich? : Weil ich meinen PCs früher gerne Frauennamen gegeben habe...) liebevoll "Testsystem" .

Das automatische Update auf dem Testsystem via GUI schlägt fehl mit der Fehlermeldung FW014 Read / Write error gefolgt von FW999 Update nicht erfolgreich.

"Ach Du liebes Lieschen" denke ich, "Was sitzt Dir denn jetzt quer?". Ich reboote, versuche es erneut und erhalte das selbe Ergebnis.

"Dann halt das Update über SSH". Gedacht getan, starte ich das Update via SSH.

Es endet ebenfalls erfolglos. Mega ärgerlich für mich, jemanden der die Linux Shell mal so gar nicht leiden kann, eben weil ich keine Ahnung von dem gesamten OS, den Befehlen und Syntax habe.

Ärgerlich deshalb, weil ich weiß, dass es ab jetzt genau hier weitergeht um das Problem zu lösen.

Die Problematik im Thread zur neuen Firmware längst mitgeteilt, schwinden langsam die Posts zu den ersten Erfahrungen der Community mit dem Update,

stattdessen kommen Ratschläge und mögliche Lösungsansätze zu meinem Problem. Definitiv an der falschen Stelle, im falschen Thread, aber ich bin dankbar für jede Idee.

Ist eben das nicht eine Community - sofort hilfsbereit zur Stelle?

Wohlwissend dass ich meinen eigens für die Community eröffneten Thread nun für mich selbst kapere, gehe ich auf jeden Hinweis ein und poste alles, was ich rausgefunden habe oder worüber ich nachdenke.

rednag hat recht. Zu viel für den Thread, es ist sogar irgendwie schon ein Blog...

[DER GRUND DES PROBLEMS]

Es gilt also via SSH herauszufinden, was nun das Problem ist, was der read / write error zu bedeuten hat.

Dazu habe ich das Update einfach nochmal gestartet, mir aber diesmal bewusst die Ausgaben der Shell reingezogen. Schnell wurde klar, dass der Datenträger sdb, das ist das DOM, nicht beschrieben werden kann.

Ein kurzer Ausflug: Was ist überhaupt das DOM?

Der/die/das/sch****drauf DOM (Disk on Module, lt. QNAP auch Disk on Motherboard) ist ein Speicher, der "fest" mit dem Mainboard des QNAP verbunden ist.

Auf dem DOM befinden sich einige für den Betrieb erforderlichen Daten, so zum Beispiel das "Grundbetriebsystem" QTS in der letzten Firmware-Version mit der das DOM im Einsatz war,

damit das Gerät auch ohne auf den HDD installiertem QTS starten kann und so z.B. die Installation von QTS auf den HDD einleitet. Außerdem liegt das BIOS (Aussage QNAP) auf dem DOM.

Es wird beim Einschalten des QNAP also immer vom DOM gebootet. Erkennt das "Grund-QTS", dass Datenträger mit einem installierten QTS eingesetzt sind, wird dieses geladen.

Andernfalls wird eben die Installation von Datenträgern und QTS eingeleitet. Das DOM bildet somit einen Grundbestandteil des QNAP ohne dem nicht viel funktionieren kann.

Zurück zum Problem... die Ausgabe der Shell beim Updateversuch lässt darauf schließen, dass der DOM schreibgeschützt ist und deshalb nicht mit dem Update beschrieben werden kann.

/dev/sdb2 contains a ext2 file system while setting up superblock

mount: block device /dev/sdb2 is write protected, mounting read-only

Lauten ein paar Ausgaben der Shell.

Aber warum soll der DOM überhaupt beschrieben werden? Das QTS befindet sich doch auf den Festplatten?!

Wie zuvor schon erwähnt, befindet sich auf dem DOM immer die Firmware-Version, mit der das DOM zuletzt in Betrieb war, daher muss der DOM mit der neuen Version beschrieben werden,

ferner muss das "Grund-QTS" natürlich ebenfalls Updates erhalten.

Ich starte also ein paar Spielereien mit dem besagten Datenträger sdb, das zuvor erwähnte sdb2 ist lediglich eine von mehreren Partitionen auf dem Datenträger.

Ein Versuch ihn zu mounten ist erfolgreich, allerdings bekomme ich (erneut) die Meldung, dass der Datenträger nur lesend gemoutet werden kann. Doof.

Ich starte eine Datenträgerprüfüng mittels e2fsck, welche zunächst fehlschlägt, da der Datenträger read-only ist.

Mit e2fsck -n für read-only Datenträger erhalte ich die Information, dass die Partition sdb1auf dem Datenträger fehlerhaft ist, mehrere Blöcke in Inode 74 sind defekt.

Was sagt uns das? Mir überhaupt nichts, ich verstehe nur, dass hier etwas nicht sauber ist. Linux jedenfalls versetzt Datenträger unter Umständen in den read-only Modus, wenn das Dateisystem beschädigt ist. Genau das scheint mein Problem zu sein.

Warum und wieso es dazu gekommen ist weiß nur der Teufel, Fakt ist einfach, dass technische Geräte mal kaputtgehen, außerdem ist meine 251+ ja nicht umsonst ein Testsystem, ich habe also schon viel Schindluder mit ihr getrieben, möglicherweise ist ihr hier etwas nicht gut bekommen...

[DIE LÖSUNG DES PROBLEMS]

Eine Reparatur durch e2fsck ist leider ausgeschlossen, da der Datenträger ja read only ist.

Nach etwas, naja einiger, Recherche bin ich auf das Thema "Superblock" gestoßen.

Der Superblock ist ein grundlegender Bestandteil eines Dateisystems unter Unix oder eben dem Dateissystem ext2, von dem automatisch Backups angelegt werden, welche man bei Bedarf laden kann.

Beim Versuch ein Backup des Superblocks zu laden stellte ich leider fest, dass es in diesem Fall keine Backups gibt und somit schwand nun auch die Hoffnung, dass ich das Problem mit ein paar Shell-Eingaben beheben kann.

Die nächste Option war ein Firmware Recovery, parallel wendete ich mich bereits an den QNAP Support mit der expliziten Frage, wie ich den DOM aus dem read-only Modus rausbekomme.

Die relativ prompte Antwort vom Support war, dass es sich wahrscheinlich um einen Defekt des DOMs handelt, ich aber eine Recovery versuchen kann.

Worin unterscheidet sich die Recovery Firmware eigentlich von normalen FW Images?

Ganz einfach: das Image enthält auch Informationen über den logischen Aufbau des DOM, also Partitionsinformationen und schreibt den kompletten DOM neu anstatt einfach nur Dateien zu aktualisieren, wie es bei normalen FW Images der Fall ist.

Also habe ich alles für meine übrigens erste Firmware Recovery vorbereitet. An dieser Stelle hatte ich mich bereits eingehend über das Verfahren informiert und somit hätte ich eigentlich schon vorher

absehen müssen wie das Ganze ausgeht, aber der Reihe nach...

Die offizielle Anleitung sieht vor, den QNAP mittels USB Speicher in ein ins RAM geladenes Linux Betriebssystem, der "Damn Small Linux" oder "DSL" Distribution zu laden.

Erster Stolperstein war es in den Bootmanager zu gelangen. Mit F11 sollte das gehen, tat es aber nicht. Ich musste die Bootorder also im BIOS direkt einstellen.

Anschließend schlugen etliche Versuche beim Laden des OS fehl, die Ausgabe war sinngemäß, dass die Hardware-Autoerkennung nicht erfolgreich abgeschlossen werden konnte.

Es endete stets mit "nosignal" am Monitor.

Kurzerhand entschloss ich mich also ein anderes OS als Linux DSL zu verwenden, denn alles was ich brauchte war ja die Möglichkeit, das Recovery Image von USB auf den DOM zu kopieren...

spätestens hier hätte ich nochmal wissen müssen, dass das Vorhaben zum Scheitern verurteilt ist.

Nebenbei fand ich heraus, dass es häufig zu Problemen mit DSL kommt und daher andere OS für die Recovery empfohlen werden.

Ich machte also einen Stick mit xubuntu fertig, von dem ich dann auch problemlos booten konnte. Nun hieß es mittels Shell das Recovery Image auf den DOM zu kopieren.

Vollidiot! Wie denn wenn das DOM read-only ist? Den ganzen Aufwand hätte ich mir getrost sparen können, versuchte es aber dennoch.

Ergebnis: Die Shell zeigte mir unverblümt wie blöd ich bin, genauer sagte sie aus, dass der DOM read-only ist und die Datei nicht kopiert werden kann.

Ich habe also wieder Mr. Google bemühen müssen, mir zu erklären welche Möglichkeiten es noch gibt.

Als vielversprechende Möglichkeit bin ich auf dd (diskdump) gestoßen, welcher nicht auf Dateiebene arbeitet sondern die Daten logisch kopiert.

Doch auch hier scheitert es, das Image auf das DOM zu übertragen.

Da es nicht auf Dateiebene arbeitet sondern logisch dürfte das Problem meinem Verständnis her demnach nicht mit dem fehlerhaften Dateisystem zusammenhängen, sondern in der Tat mit einem defekten DOM... dem heiligen DOM.

Wie es der Zufall aber will, habe ich gerade ein kleines Arsenal an defekten QNAP rumliegen, hauptsächlich aus der 451er Serie.

So kam mir natürlich der Gedanke, einfach ein funktionierendes DOM aus einem der Geräte zu nehmen.

"Geht das? Dieses heilige Teil einfach ersetzten? Warum nicht, es ist doch nur ein blöder USB Speicher!"

Der Austausch des DOM war nicht sonderlich kompliziert, lediglich ein wenig prikär, da die Steckverbindung verklebt ist und man die Verklebung erst lösen muss, damit man die Kontakte nicht abreisst.

Ich habe das vorsichtig mit einer Cutterklinge gemacht. An der Stelle sei erwähnt, dass nicht jedes QNAP NAS mit einem gesteckten DOM versehen ist, beim TS-451A zum Beispiel ist der DOM fest auf dem Mainboard integriert.

Nachdem der DOM getauscht wurde und ich das Gerät ohne HDD eingeschaltet habe, starrte ich gespannt auf meine beiden Monitore, der eine am QNAP, der andere mit geöffneten QFinder.

"Was wird mir gleich präsentiert werden? Gar nichts, oder ein falsches Gerät wie eine TS-451 aus der der DOM stammt?"

Die Freude war groß, als ich sah, dass eine TS-251+ erkannt wurde und das Gerät einwandfrei startete. Ich schaltete es ab und setzte die HDD rein, startete das Gerät. Auch hier einwandfreies Booten ins QTS.

Über die GUI erfuhr ich, dass die Firmware inkonsistent sei. Klar, denn auf dem DOM befand sich eine ältere QTS Version als auf den HDD. Ich startete also das Update auf die aktuelle 4.4.3 1439.

Das Update erfolgte problemlos, der anschließende Neustart ebenfalls.

Die Ernüchterung kam jedoch schnell: Die Firmware ist inkonsistent hieß es auch nach mehreren Neustarts und erneuten Updates, welche mir von QTS vorgeschlagen wurden.

Ich hatte mir schon gedacht, dass man den heiligen DOM nicht einfach wie einen RAM austauschen kann und entschloss mich, es mittels Firmware Recovery neu aufzusetzen.

Das funktionierte erwartungsgemäß einwandfrei.

Ich startete nun schrittweise, beginnend mit QTS 4.3.6 den DOM wieder auf die aktuelle Build zu aktualisieren.

An dieser Stelle nochmals Dank an UdoA für die Bereitschaft mir ältere Builds bereitzustellen, leider war es mir durch diese nächtliche Spontanaktion aber nicht möglich auf das Angebot zurückzukommen.

Das System startete nun erneut einwandfrei, die Meldung über eine inkonsistente Firmware blieb aus und das System rödelt nun seit über einem Tag in exakt dem Zustand vor dem Eingriff vor sich hin, als wäre nie etwas gewesen.

Das heilige DOM... wohl doch eher nur ein einfacher Speicher, der lediglich eine wichtige Funktion hat.

Meine weiteren Gedanken gehen nun dahin, den defekten DOM irgendwie wieder fit zu bekommen. Ob ich mir diese Arbeit mache steht aber noch in den Sternen, es wäre rein interessehalber für den Fall, dass man nicht gerade mit DOMs um sich werfen kann oder das DOM eben nicht ausgetauscht werden kann.

Sollte ich mir die Zeit dafür nehmen, werde ich hier selbstverständlich berichten, jetzt freue ich mich erstmal über den bisherigen Erfolg.

Cheers!