Der Versuch ein abgeschriebenes DOM mit "r/w error" wieder fit zu bekommen

[EPILOG]

In diesem Artikel habe ich beschrieben, wie ich mit dem Problem eines read/write Errors am DOM klargekommen bin und den DOM erfolgreich ersetzt habe.

Dazu hatte ich das DOM meiner TS-251+ durch das einer defekten TS-451 ersetzt. Aufgefallen ist das Problem beim Firmwareupdate, welches nicht durchgeführt werden konnte.

Daran anschließend möchte ich hier über den Versuch berichten, den DOM mit diesem Fehler wieder fit zu bekommen, denn klar ist, dass nicht jeder DOMs als Ersatzteil gebunkert hat, außerdem ist der DOM schlichtweg nicht bei allen Modellen austauschbar.

Manch einer wird sich nun fragen, wieso ich den Weg nicht umgekehrt gegangen bin, warum ich nicht erst versucht habe den DOM fit zu bekommen, sondern den vermeintlich "schwierigeren" Weg des Austauschs gegangen bin.

Das Problem war ja, dass ich den DOM nicht mehr beschreiben konnte, was meines Wissens nach nur bei einem Firmwareupdate erforderlich ist.

Demnach konnte ich das NAS problemlos so weiterbetreiben, nur halt für immer auf dem gleichen Firmwarestand.

Die wenigen Versuche am DOM noch etwas umzureissen waren nicht sonderlich kritisch, sodass ich nicht berfürchten musste, mein gesamtes System zu schrotten.

Bei nachfolgenden tieferen Eingriffen hätte ich das NAS vermutlich entsorgen können, wenn etwas nicht geklappt hätte.

So konnte ich in Ruhe mit einem anderen DOM rumprobieren und hätte im Ernstfall wieder meinen "halbfunktionierenden" DOM genommen.

[DIE ERSTEN ÜBERLEGUNGEN]

Dieser Step war relativ schnell abgehakt. Ich habe einen Datenträger der nicht beschreibbar ist und muss ihn wieder beschreibbar machen. Das ist alles.

Ich überlegte wann ich sowas zuletzt gemacht hatte, schließlich gehören nicht beschreibbare USB Sticks irgendwie zum Alltag. "Sch**** Wegwerfgeneration" denke ich mir. Problematische USB Sticks landen bei mir nämlich direkt im Müll, ich habe ein derartiges Problem also scheinbar noch nie behandelt. Also fangen wir mal an, aber an welchem Gerät?

Mein frisch instandgesetztes Testsystem wollte ich nur ungern nochmal auseinanderpflücken, aber da wären ja noch ein paar defekte TS-451x von denen eins nach dem Booten zumindest erreichbar ist. Also sollte dies mein "DOM-Reparatursysten" werden.

Welche Möglichkeiten gibt es, überhaupt Zugriff auf den DOM zu erlangen?

1. Da wäre zum einem SSH, was jedoch zunächst ein funktionierendes QTS auf einer HDD voraussetzt, jedenfalls soweit ich das zum jetzigen Zeitpunkt erfahren habe.
   Ob dies bei dem defekten TS-451 möglich ist wird sich erst zeigen müssen.
2. Eine andere Möglichkeit, welche mir zunächst vielversprechender aussieht, wäre ein ins RAM geladenes OS mit dem ich auf den DOM zugreifen kann,
   denn beim Zugriff über SSH könnten Teile des DOMs in Verwendung sein, was meine Möglichkeiten einschränken würde.
3. Eine weitere Möglichkeit sehe ich darin, den DOM, der (augenscheinlich) über eine einfache USB Schnittstelle angebunden ist, an einem anderen PC anzustöpseln.
   Der Nachteil daran: Bei manch einem Gerät mit festem DOM wäre dies nicht möglich, daher ist das erstmal die letzte Option.

Laut QNAP (Auskunft vom Support) befindet sich auch das BIOS auf dem DOM, was für mich im ersten Moment danach klingt, dass der DOM am QNAP ständig in Benutzung ist.

So wirklich glauben kann ich das auch gar nicht, da ich der Meinung bin einen QNAP schonmal ohne DOM eingeschaltet und Zugriff auf das BIOS gehabt zu haben.

Hier fange ich dann wohl an und erhoffe auch mir die Fragen beantworten zu können, wie der DOM aufgebaut ist und wofür die 5 Partitionen auf dem DOM da sind.

Welche Möglichkeiten ich habe, den DOM, bzw. einen USB-Datenträger zu reparieren, suche ich mir dann heraus, wenn ich den Zugriff darauf hergestellt habe,

da die Verfahren sicherlich abhängig von der Art und Weise sein werden, wie ich auf das DOM zugreife und welche Tools dafür verfügbar sind.

Ich stelle gerade fest, dass ich das Teil mal das DOM und mal der DOM nenne... Disk on Module... eigentlich doch eher die DOM... aber das klingt mir zu blöd, deshalb mache ich einfach weiter wie bisher

[DIE RECHERCHE - EINBLICKE IN DEN DOM]

Ziemlich sicher, dass ich nicht alle Informationen die ich haben möchte auf eigene Faust herausfinden würde, habe ich mir alles was ich zum Thema DOM finden konnte einmal angeschaut.

Dabei bin ich auf diesen Thread im offiziellen QNAP Forum gestoßen, bei dem jemand genau das gemacht hat, was ich auch gemacht hätte, wenn ich kein Austausch-DOM gehabt hätte:

Ich hätte mir meinen DOM selbst aus einem USB Stick und USB Connector eines PC Gehäuses gebaut. Sollte mein aktuelles Vorhaben also scheitern, besteht zumindest für jeden mit austauschbarem DOM die Hoffnung, das NAS auf diese Weise wieder fit zu bekommen. Außerdem bin ich auch darauf gestoßen, dass man entsprechende DOM käuflich erwerben kann, nach Quellen habe ich nicht geschaut, denn eigentlich wollen wir einen Austausch ja vermeiden.

Zu dem Aufbau des DOM habe ich folgende Info gefunden, welche von einem User des offiziellen QNAP Forums bereitgestellt wurde, es ist also keine offiziell bestätigte Information, ich halte sie jedoch weitgehend für plausibel:

Zitat von offizielles QNAP Forum

sdb1: Boot (Size about 5 MB)
sdb2: System1 (Size about 240 MB) (marked as bootable)
sdb3: System2 (Size about 240 MB) (Backup-System)
sdb4: Extended Parititon (Size about 1 kB)
sdb5: Rootfs1 (?) (Size about 8 MB)
sdb6: Rootfs2 (?) (Size about 8 MB)

An dieser Stelle möchte ich anmerken, dass ich kein Spezialist bin und mit Linux normalerweise keine Berührungspunkte habe.

Alles was ich aus meinen Beobachtungen schlussfolgere muss nicht zwingend der Realität entsprechen.

Ich schlussfolgere daraus, dass immer von sdb1 gebootet wird, während dieser Phase wird dann entschieden, von wo das QTS geladen wird.

Diese Info spiegelt auch das wieder, was ich auf der Partition sdb1 entdecke: Den Linux Bootmanager "grub".

Dabei bin ich gerade noch auf meinem Testsystem unterwegs, denn das "DOM-Reparatursystem" muss erst noch gebastelt werden.

sdb2 und sdb3 interpretiere ich als das "Dual Boot System" welches QNAP bei einigen Modellen anpreist. Sicherlich werden Geräte mit kleineren DOMs hier nur ein System bzw. eine Partition haben.

An dieser Stelle hatte ich die Partitionen für mich bislang falsch interpretiert, da die Partitionen sdb2 und sdb3 bei der Auflistung in der Shell als "QTS_BOOT_PART2" und "QTS_BOOT_PART3" bezeichnet werden und ich aus dem Wort "Part" etwas anderes gedeutet hatte. Ein Blick auf den Inhalt der beiden Partitionen spiegelt das wieder: Beide Partitionen enthalten exakt die gleichen Daten, welche offensichtlich Hauptbestandteil von QTS sind. Würde ich zwischen zwei Firmwareupdates (also zwischen Installation und Booten von QTS) auf diese Partitionen blicken, könnte ich vermutlich Unterschiede feststellen: Eine Partition mit den Daten der vorherigen Version, und eine mit den Daten der neuen Version.

sdb4 habe ich in grauer Schrift dargestellt, da es diese bei mir nicht gibt (funktionierender DOM), das war auch schon vorher der Fall, also beim defekten DOM.

Mit sdb5 und sdb6 kann ich wenig anfangen, auch wenn ich nun grob weiß was rootfs ist, kann ich durch das bloße Anschauen und Stöbern in den Partitionen nichts erkennen womit ich das bestätigen kann.

Ich stelle lediglich fest, dass sdb5 leer ist... naja bis auf einen lost+found Ordner.

sdb6 enthält u.a. zwei Configdateien. Mit vim schaue ich sie mir an und wundere mich ein wenig: Wieso stehen hier Daten, die ich im QTS eingestellt habe, wie z.B. der Name des Geräts oder die Arbeitsgruppe?

Dies werde ich auch nochmal mit einem Gerät prüfen, in dem zu diesem Zeitpunkt dann keine HDD mit installiertem QTS eingesetzt sind, denn bislang hieß es immer, dass auf dem DOM keinerlei "persönliche" Daten abgelegt sind.

Neben den bereits genannten Daten finde ich sonst "nur" konfigurierte Ports, z.B. für SSH sowie Angaben darüber, welche Dienste wie z.B. Photostation, Twonky etc. aktiviert oder deaktiviert sind, also ebenfalls persönliche Einstellungen.

Viel mehr lässt sich über den DOM oder gar dessen Aufbau und Inhalt nicht so richtig aus google herausquetschen, auch das Durchforsten der einzelnen Partitionen gibt mir wenig Aufschluss.

[SUCHE NACH ANTWORTEN UND VERSUCH DER SOFTWARESEITIGEN PROBLEMLÖSUNG]

Eigentlich wollte ich damit beginnen, zu prüfen ob es ohne DOM ein BIOS und weitere Funktionen gibt.

Das mit den "persönlichen Einstellungen" auf dem DOM lässt mir aber keine Ruhe, und so habe ich den DOM in eine TS-451 ohne HDD gesteckt und das System in meine xubuntu live Distribution gebootet.

Nachdem ich die DOM Partitionen (natürlich nur read-only; wir erinnern uns: das ist ja das Problem das behandelt werden soll) gemountet habe und mir die Datei namens uLinux.conf auf sdb6 erneut mit einem Editor angeschaut habe, die Entwarnung:

Die Datei enthält nur Standarddaten, wie man es von einem frischen System kennt. Der Gerätename lautet z.B. NAS07EDBC. Hier wird also wirklich nichts, auch nicht temporär, vom vorherigen System gespeichert.

Neustart des System mit Boot vom DOM.

Ich lande an der Stelle, an der das "Grund QTS" nach einem Datenträger verlangt und so bekommt es eine SSD von mir spendiert, welche jedoch nicht erkannt wird.

Das hatte ich fast erwartet, denn die vier HDD LEDs leuchten permanent rot und haben dies schon angedeutet, nun weiß ich wenigstens wieder warum das Gerät als "defekt" deklariert ist.

Somit scheidet meine Möglichkeit 1 von oben, wie ich Zugriff auf das DOM erlange zunächst aus.

Das macht aber nichts, da ich früher oder später - sollte ich Erfolg haben - sowieso ein Firmware Recovery durchführen muss...

und dazu muss ich ohnehin wie in der Möglichkeit 2 vorgesehen über ein anderes OS meiner Wahl, in diesem Fall xubuntu, booten.

Das tue ich auch. Den Vergleich der Daten mit dem funktionierenden DOM im Testsystem erspare ich mir, denn ich erwarte hier keine Unterschiede, außer eben einer älteren QTS Build auf dem defekten DOM.

Was mir sofort zwangsläufig auffällt ist, dass ich in diesem Gerät nun auch ein sdb4, die extended Partition habe. Scheint also irgendwie geräteabhängig zu sein, aber sei es drum.

Zunächst erstelle ich ein Image des defekten DOM, in der Hoffnung den Fehler mitzunehmen um so später weiter forschen zu können, falls ich den DOM komplett abschieße oder ich nochmal Einsicht haben möchte.

Leider wird der Fehler nicht mitgenommen, nach dem Mounten des erstellten Image erhalte ich auch Schreibrechte. Klingt plötzlich wieder so, als wäre der DOM hardwareseitig defekt.

Ich fahre also damit fort den DOM irgendwie wieder beschreibbar zu bekommen.

Erster Versuch mit wenig Hoffnung, dass es auch ohne Schreibrecht klappen kann, ist fdisk. Das Tool jedoch meckert gleich von Beginn an, dass es mit einem r/o Datenträger nichts anfangen kann. Abgehakt.

Mein nächster Gedanke geht an das Tool gparted von dem ich gelesen habe, dass man damit r/o USB Sticks wieder fit bekommt.

Ich habe mich zwar nun so langsam an SSH gewöhnt, jetzt muss ich aber wieder auf eine GUI umsteigen. Gefällt mir irgendwie

Kein Gefallen finde ich an dem Ergebnis: auch hier nur die Meldung, dass der Datenträger r/o ist und daher keine Änderungen vorgenommen werden konnten.

Anschließende Versuche den DOM wieder in den r/w Modus zu versetzen schlugen fehl, ich will jetzt aber nicht noch mehr mit den Details langweilen...

Egal was ich bis hierhin alles mit google herausfinden konnte: als letzte Option war immer im Gespräch den Datenträger mit einem Windows PC zu bearbeiten.

Schade, da es ja auch DOM gibt die man nicht entnehmen kann, um an dieser Stelle fortzufahren.

Für den nächsten Step muss ich den DOM also an einen Windows PC anschließen. Um mir Bastelarbeit zu ersparen, entschließe ich mich dazu mir einen PC raus zu suchen, um einen USB Pin Header auf dem Mainboard zu verwenden.

Das ist der Anschluss, an dem z.B. USB-Buchsen vom PC Gehäuse angeschlossen werden.

Leider ist die Schnittstelle nur in der Theorie identisch mit der des DOM, denn hier kochen die Hersteller unterschiedliche Süppchen, sodass die PIN Belegeung variieren kann.

Die Belegung des Mainboards zumindest kann man ermitteln, beim DOM ist das schon etwas komplizierter. Glücklicherweise stellt sich nach etwas Recherche aber heraus, dass theoretisch nicht viel schiefgehen kann, denn der DOM besitzt einen 8+1 Pin Anschluss und nach den erster Sichtung unterschiedlicher Belegungsvarianten kann man diesen nicht aufstecken, wenn dadurch "kritsche" PIN-Vertauschungen wie GND und 5V zustande kommen würden. Lediglich bei Mainboards mit einem 4-Pin Anschluss wäre vorsicht geboten, denn hier könnte so eine Vertauschung vorkommen. Mir reicht was ich gesehen habe, eine 100% Sicherheit werde ich hier nicht ohnehin nicht erlangen können, solange mir QNAP die Belegung des DOM nicht aus erster Hand verrät.

Beim Blick in die beiden PCs die für das Unterfangen in Frage kommen stelle ich jedoch fest, dass es aus Platzgründen gar nicht so einfach ist den DOM anzustecken:

Immer ist ein anderer Stecker, das Gehäuse oder irgendwas anderes im Weg, was ich nicht einfach entfernen kann oder will. Bevor ich hier ein passendes System finde, entscheide ich mich um:

Ich nehme ein USB Kabel, schneide es durch und bastle mir eigene Pins aus den Adern einer Fernmeldeleitung. Zugegeben eine Bastellösung, aber für den Versuchsaufbau taugt es.

In der Hoffnung, dass die Farben der Adern und die Belegung des DOM passt, stecke ich das Kabel an den DOM und den USB A Stecker anschließend an meinen mit Win10 gestarteten PC.

Der DOM blinkt, auf dem Bildschirm hagelt es Meldungen, dass der Datenträger geprüft werden muss sowie dass der Datenträger nicht lesbar ist und formatiert werden muss.

Das habe ich erwartet, denn der DOM ist mit ext2 formatiert und meine Windows Installation kann das bislang nicht. Ab in die Datenträgerverwaltung... gefunden werden 5 Partitionen, wie erwartet.

Ich starte direkt den ersten Versuch eine Partition zu löschen. "Die Anforderung konnte wegen eines E/A-Gerätefehlers nicht ausgeführt werden." lautet die Fehlermeldung, selbes Verhalten (natürlich) auch bei diskpart.

Der Versuch einer Formatierung ergibt die Meldung, dass der Datenträger schreibgeschützt sei, das spiegelt sich auch in den Eigenschaften des Datenträgers sowie in der Datenträgersoftware "EaseUS" wieder.

Ebenfalls mit diskpart und attributes disk clear readonly versuche ich den Schreibschutz zu entfernen. Die Ausgabe verzeichnet zwar einen Erfolg, geändert hat sich aber nichts.

Auch der Versuch den Schreibschutz über die regedit zu entfernen bleibt erfolglos. Weitere Ideen habe ich nicht und finde ich auch nicht.

Es scheint so, als handle es sich wirklich um einen Hardwaredefekt, warum auch immer der aufgetreten sein mag. Hardware geht nunmal kaputt.

Da war ja noch die Sache mit dem BIOS, was laut Aussage von QNAP auf dem DOM liegen soll.

Da der DOM ausgebaut ist, starte ich den QNAP einfach mal ohne DOM, der Xubuntu Stick steckt noch. Es wundert mich nicht, dass Xubuntu geladen wird, wofür ein BIOS erforderlich wäre. Auch wundert es mich nicht, dass ich nach einem Neustart ins BIOS komme und alles so vorfinde, wie ich es verlassen hatte. Das BIOS befindet sich also nicht auf dem DOM, zumindest nicht in meinem Fall.

Den Versuch QTS ohne DOM von einer HDD zu laden kann ich aufgrund des Defekts an dem QNAP nicht durchführen. Da standardmäßig jedoch vom DOM gebootet wird und die eingesetzen HDD soweit ich mich erinnern kann nicht in der Boot Order auftauchen, gehe ich aber davon aus, dass QTS ohne DOM nicht hätte geladen werden können, jedenfalls nicht mit Standardeinstellungen im BIOS. Ob das QTS auf den HDD überhaupt allein bootfähig ist, ist eine andere Frage.

Mir egal, der Auftrag war es den DOM zu retten und das ist mir nicht geglückt.

[VERSUCH DER HARDWARESEITIGEN PROBLEMLÖSUNG]

Ein letztes Mal schaue ich mir den DOM hardwareseitig an, bevor alles auf dem Müll oder wo auch immer landet, aber was soll ich hier mit bloßem Auge als Defekt ausmachen können?

Gar nichts. Oder? Moment! Zwischen den ganzen SMD Widerständen und anderen Bauteilen sticht mir eines sofort ins Auge:

Vier Lötpunkte von denen sich jeweils zwei nebeneinander befinden. Beschriftet sind sie mit 1 und 2 sowie 3 und 4.

Zwischen 1 und 2 befindet sich ein Bauteil, zwischen 3 und 4 nichts.

Darüber, fast schon herausfordernd, ist folgendes aufgedruckt:

1,2 R/W

3,4 W/P

R/W = read/write? W/P = write protected? Was für eine schöne Einladung! Doch was könnte hier passiert sein?

Dem ersten Anschein nach muss eine Brücke oder auch ein Widerstand zwischen die Lötpunkte 1 und 2, damit der DOM beschrieben werden kann. Ich tippe spontan auf eine Brücke.

Da ist ja auch irgendwas, aber vielleicht ist es defekt oder weicht zu sehr von seinem Sollwert ab. Möglicherweise muss auch etwas zwischen die Lötpunkte 3 und 4, ein Bauteil welches hier möglicherweise abhanden gekommen ist.

Den exakten Sollzustand kann ich anhand des vorliegenden DOM nicht ermitteln, aber ich habe ja die Möglichkeit mir einen Funktionierenden anzuschauen.

Von diesem will ich ermitteln, was für ein Widerstandswert (~ 0,1 Ohm = Brücke) benötigt wird und ob eventuell zwischen den Lötpunkten 3 und 4 auch noch etwas sein muss.

Eine kurze Messung am defekten DOM gibt zumindest schonmal Aufschluss über die vorliegende Situation:

Das Bauteil zwischen 1 und 2 scheint eine Brücke zu sein, ich messe hier 0,1 Ohm, also den Widerstand der Messleitungen und Kontaktübergänge. Zwischen 3 und 4 messe ich ziemlich exakt 12 kOhm,

je nachdem wie ich die Messspitzen ansetze aber auch mal 72 kOhm, das kommt mir spanisch vor.

Bei beiden Messungen werde ich höchstwahrscheinlich in den Speicherchip gemessen haben, denn dieser befindet sich direkt auf der Rückseite, entfernen kann ich ihn nicht.

Möglicherweise ist das kleine Dingens zwischen 1 und 2 aber auch keine Brücke, sondern ein defekter Widerstand. Das gilt es zu prüfen.

Der Vergleich mit einem funktionierenden DOM gibt Aufschluss: Nachdem ich auch die Spannungen gemessen habe, stellt sich zunächst heraus, dass zwischen 1 und 2 tatsächlich eine Brücke ist, zwischen 3 und 4 nichts.

Der einzige Unterschied der auszumachen ist, ist der Widerstand zwischen 3 und 4. Dieser ist bei dem defekten DOM 12 kOhm oder 72 kOhm, bei dem funktionierenden sind es 250 kOhm, egal wie ich die Messspitzen ansetze.

Nun unterscheiden sich die beiden DOM lediglich in einem Zeichen der Typenbezeichnung, der unterschiedliche Widerstand selbst ist also kein Garant dafür dass es daran liegt,

aber es ist Naheliegend, dass genau hier etwas nicht stimmt, vor allem bei dem wechselnden Widerstand des defekten DOM.

Mir kommt in den Sinn, einfach nochmal mit nem Lötkolben über die beiden Kontakte zu braten.

Hoffnung habe ich jedoch nicht, da ich bei einer defekten Lötstelle einen anderen Widerstandswert erwartet hätte, aber das bisschen Aufwand betreibe ich gerne.

Außerdem überlege ich was passieren mag, wenn ich die Brücke zwischen 3 und 4 kurzfristig schließe und den DOM nochmal am USB anstecke.

Nachdem ich einmal über die Kontakte gebraten habe zeigt sich zumindest schonmal ein anderes Bild beim Widerstand. Dieser beträgt jetzt konstant um die 150 kOhm.

Am PC angeschlossen bleibt die Flut an Fehlermeldungen diesmal aus; habe ich das Teil nun ganz geschrottet?

Nö! Die Wege von Windows sind manchmal einfach unergründbar, in der Datenträgerverwaltung ist der DOM aufgeführt, leider weiterhin schreibgeschützt.

Im nächsten Versuch wollte ich die Kontakte 3 und 4 einfach mal mit einer Krokoklemme brücken und den DOM in Betrieb nehmen, hierbei würde ich das (bislang nicht erwähnte) 3,3V Potential von Lötpunkt 3 auf 4 geben,

eventuell ist das der lebenserweckende Impuls der dem DOM fehlt. Gar nicht so einfach, mit den kleinen Beißerchen der Krokoklemmen die noch kleineren Kontaktflächen zu erwischen...

Nachdem das geglückt ist und der DOM angeschlossen wurde gab es keine Reaktion, erst nach dem Entfernen der Brücke blinkte der DOM wieder auf, blieb aber weiterhin schreibgeschützt.

Die dadurch entstandene Konstellation ist eventuell auch gar nicht vorgesehen, ich vermute die Brücke befindet sich zwischen 1 und 2 ODER zwischen 3 und 4, aber niemals zwischen beiden.

Ich habe allerdings wenig Bock, die SMD Brücke aus- und wieder einzulöten.

Löten kann ich grundsätzlich relativ gut, aber sch**** SMD, sch**** bleifreies Lot... das Ding ist so klein, dass ich selbst mit einer Pinzette Schwierigkeiten hätte es zu greifen. Und eine Pinzette habe ich hier auch gerade nicht zur Hand.

Ich bin ein wenig frustriert... und genervt...

Noch einmal stecke ich den DOM an den USB, ohne Brücke, ohne alles. Leider auch ohne Blinken der LED. Irgendwas hat dem DOM nun den Gnadenschuss versetzt.

Ob es an meiner Spielerei mit der Brücke lag oder beim Abstöpseln die Klemme verrutscht ist werde ich nicht herausfinden.

Der DOM ist hin, nichts hat geholfen... es wurde nur schlimmer, nun ist er komplett unbrauchbar.

Irgendwie hatte ich mir mehr erhofft, nach so vielen Lichtblicken die ich zwischendurch hatte.

Es wäre schön gewesen wenn User mit diesem Problem nun selbst Abhilfe schaffen könnten, auch wenn ich von diesem Problem bislang nie gehört habe.

Jedem der sich das alles nun durchgelesen hat, wäre ein Happy End sicherlich auch wilkommen gewesen.

Bleibt also zu hoffen, dass aus diesem Artikel irgendwelche Schlüsse gezogen werden können, eventuell dient er irgendwann als Ansatz für den Nächsten, der bereit ist Zeit in dieses Problem zu stecken und weiter zu forschen.

Trotzdem hat es mir wieder Spaß gemacht mich mit der Materie auseinander zu setzen und spiele nun mit dem Gedanken meine einstige Überlegung mit dem Selbstbau eines DOM umzusetzen, quasi als Wiedergutmachung für diejenigen, die die Hoffnung hatten hier eine Anleitung zu finden wie man den DOM reparieren kann.

Aber erstmal steht ein weiterer Artikel an, den ich aus "aktuellem Anlass" parallel vorbereitet habe: Eine kurze Zusammenfassung von DOM und Firmware Recovery und wie eine Recovery alternativ zur Beschreibung von QNAP durchgeführt wird.

Schade dass es so gelaufen ist, ein Bier trinke ich trotzdem darauf.

Cheers!