Vorweg noch einmal etwas zum "Prinzip": Es geht auch nicht um bewußtes Lügen bei meinen Worten mit den "ehrlichen Ansagen" ... aber oft genug erlebt man es auch, daß zwischenzeitliche Versuche "verschämt" verschwiegen werden, weil einem im Nachhinein dann selbst bewußt wurde, was man da - häufig - für Unsinn veranstaltet hat. Beispiele dafür, die sich erst nach mehrfachem, hartnäckigen Nachfragen etwas erhellen ließen, gibt es hier auch zur Genüge (oft genug gleitet das auch ab, wie man gerade in einem anderen Thread beobachten kann, wo mal wieder jemand den Unterschied zwischen IPPF und verlängerter Werkbank des AVM-Supports nicht verstehen will) und auch Deine Versuche, in beide Partitionen dasselbe System zu installieren (und das offensichtlich auch nur nach dem "Prinzip Hoffnung" und ohne wirklich belastbare Theorie, warum das einen Unterschied machen sollte), gehören zu dem, was so mancher lieber verschweigt und was dann die Einschätzung der tatsächlichen Lage unnötig verkompliziert.
Denn man muß halt auch den Vorwurf, daß eine Aktion ohne wirkliches Nachdenken ausgeführt wurde, aushalten, wenn die Anzeichen dafür deutlich sind und man selbst keine plausible Erklärung abgeben kann, warum man das so gemacht hat. Letztlich dient auch das ja dazu, daß andere aus solchen Fehlern lernen können und sie dann ihrerseits (im besten Falle zumindest) nicht wiederholen. Ein absichtliches "Vorführen" von anderen ist hier ja oft schon deshalb eher eine (dumme) Unterstellung von "getroffenen Hunden, die bellen", weil der größte Teil der Benutzer hier anonym agiert und die Identitäten im "real life" gar nicht bekannt sind (zumindest bei den allermeisten nicht).
================================================================================================
Das Protokoll des "BootDeviceFromImage" sieht aber jetzt schon mal deutlich logischer aus, denn die Image-Größe (auch wenn das hier mit der PS-Variante erstellt wurde und nicht mit "image2ram" als Shell-Skript) ist zumindest die erwartete bzw. erwartbare ... eigentlich sollte auch die SHA256-Prüfung dasselbe Ergebnis zeigen.
Das gilt nicht zwingend für "komplette Firmware-Images", die mit meiner C#-Klasse bzw. der PowerShell-Funktion erzeugt werden, weil AVM vermutlich auch etwas Selbstgeschriebenes zum Zusammenpacken als TAR-Archiv verwendet, was sich nicht wirklich an den Standard für das "ustar"-Format hält - bei den erzeugten Dateiattributen - und meine Implementierung da anders vorgeht.
Bliebe also jetzt die Aufgabe, den Start des Systems über den ersten "trace point" zu kontrollieren. Da das Schreiben ins Urlader-Environment ("firmware_info" wird auf den Wert von "/etc/version" gesetzt) bereits in "/etc/init.d/S01-head" erfolgt und die Entscheidung zum Flashen (oder auch dagegen) erst in der "/etc/init.d/E03-flash_update" erfolgt, kann man an diesem Wert erkennen, wie weit (wenn überhaupt) die Box gestartet werden konnte.
Dazu löscht man zuerst den Wert von "firmware_info" über den FTP-Server (das hatte ich oben mit einem "UNSETENV" bereits angesprochen) und lädt danach noch einmal ein System mittels "BootDeviceFromImage" in den Speicher. Wenn man dann - nach ca. 4-5 Minuten - das Gerät selbst neu startet und per FTP-Client nach den jetzt vorhandenen Urlader-Variablen schaut, kann man an der Tatsache, ob "firmware_version" neu gesetzt wurde, schon vieles ablesen ... erstens muß dazu dann das Root-FS erfolgreich gemountet worden sein (weil die Shell-Skripte erst dort enthalten sind) und zweitens ist der "init"-Prozess so weit gestartet worden, daß die Datei "/etc/init.d/rc.S", die als eine Art "Master-Prozess" für die verschiedenen Start-Skripte dient, verarbeitet wird.
EDIT: Ein "UNSETENV" und ein "BootDeviceFromImage" kann man auch in einem einzigen Aufruf von "EVA-FTP-Client.ps1" machen lassen. Ein "SetEnvironmentValue" ohne neuen Wert, führt zu einem "UNSETENV" (die möglichen Aufrufe sind in der Skript-Datei aufgelistet) und mehrere Kommandos oder Funktionen verknüpft man unter der PowerShell auf einer Zeile (oder auch in einem "ScriptBlock") mit einem Semikolon dazwischen.
Außerdem will ich mal festhalten, daß das Kriterium "Die Box ist danach über den Browser nicht erreichbar." höchstens ein Symptom ist und nicht immer auch ein Indiz Beweis (höchstens ein Indiz) dafür, daß die Box gar nicht gestartet werden konnte. Das kann alle möglichen anderen Ursachen haben (bis hin zum falschen "Branding" im Bootloader, was bei der 7590 auch nicht ohne weiteres zu ändern ist, und der Installation einer Firmware, die nicht dazu paßt - was hier, nach der Ansicht des Environments, aber nicht der Fall ist) und man kann noch auf anderen Wegen feststellen, ob die Box tatsächlich nicht startet bzw. wie weit die Initialisierung vorankommt. Denn was hier ja - ausgehend von der Beschreibung in Prosa - auffällt, ist die Tatsache, daß die Box gar nicht in eine Boot-Schleife verfällt ... was eben ein deutlicher Unterschied zu dem Problem in #1 ist, das ursprünglich zur Erstellung dieses Threads führte.
Ich würde also erst mal ermitteln (im zweiten Schritt, der erste Vorschlag steht oben und der zweite Schritt macht auch nur Sinn, wenn die Box wenigstens bis zum Start der Initialisierung kommt), ob z.B. die Box per "ping" erreichbar ist bzw. auf einem PC, der auch nur mit dieser Box per LAN-Kabel verbunden ist und mit nichts anderem, damit da kein weiterer Traffic hinzukommt, mal den Startvorgang der FRITZ!Box mitschneiden (ohne eigene Aktionen) - eine startende Box meldet sich auch mit allen möglichen anderen Aktivitäten im Netzwerk, bis hin zur Suche nach PLC-Adaptern auf OSI-Layer 2. Daß die Box selbst dabei nur an die Stromversorgung angeschlossen und per Kabel mit einem einzigen Client (ebendiesem PC) verbunden ist und weder mit Telefonen, DSL-Anschluß oder USB-Geräten, versteht sich - bei einer Fehlersuche - hoffentlich von selbst.
Mit den Ergebnissen solcher Tests kann man sich dann genauer überlegen, wo die Box wohl ein Problem haben könnte ... aber die allerersten Schritte (zumindest bis zum Abschluß der Initialisierung) sind auch noch mit einem Watchdog abgesichert, der in "/etc/init.d/S05-watchdog" aufgesetzt wird und einen automatischen Neustart auslösen müßte, wenn die Initialisierung nicht innerhalb von 120 Sekunden zum Ende kommt.
Jetzt kann man schon hier überlegen, ob das System überhaupt nicht bis zum Setzen dieses Watchdogs kommt (beim Start aus dem RAM kommt die "E03-flash_update" ja tatsächlich auch noch davor, aber auch die hat eine Signalisierung über LEDs, ob sie flashen will oder nicht) oder ob nicht doch sogar die komplette Initialisierung beendet werden kann, auch wenn irgendwelche Dienste oder Einstellungen vielleicht nicht stimmen.
Und um auch das nicht komplett aus den Augen zu verlieren als mögliche Problemursache ... ich habe auch schon Fälle gehabt, wo am Ende irgendeine Security-Suite auf dem verwendeten Windows-PC für die merkwürdigsten Symptome sorgte - da ist ein nicht funktionierender Zugriff mit einem Browser noch lange kein zuverlässiges Indiz. Hier wäre also auch ein zusätzlicher Versuch mit einem zweiten Client oder auch die Prüfung, ob die Box das WLAN aufzieht (was aber per LED signalisiert werden müßte, daher glaube ich in diesem konkreten Fall auch nicht daran, das ist mehr ein Hinweis an andere Leser), ein weiteres Puzzle-Teil.
Das Unterbrechen der Stromversorgung bei der Verwendung des Recovery-Programms KANN zwar tatsächlich zu einem Problem führen (das sehen wir ja hier an #1 ff.), aber die Wahrscheinlichkeit dafür ist nun auch wieder nicht sooo groß, daß zwei solche Fälle in so kurzem Abstand die logischste Erklärung wären - m.W. war der Fall aus #1 tatsächlich auch der erste, zumindest wenn es um "hier berichtet" geht, der den Weg ins IPPF gefunden hat. Ich kenne jedenfalls keinen weiteren Bericht, daß der Inhalt eines NAND-TFFS so zerstört wurde, daß es zu den Werten aus diesem ersten Fall hier im Thread kam.
Denn - anders als es z.B. die Anzeige in der Support-Datei oder die Ausgabe im FTP-Server suggerieren mag - die Werte aus diesem Environment stehen eben nicht hintereinander in dieser Partition (schon gar nicht in sortierter Folge) und in #1 war vermutlich eher ein unvollständiger Löschvorgang für einen NAND-Block die Ursache (als Ergebnis der Unterbrechung beim Recovery) ... und die Zeitspanne, in der das Löschen solcher Blöcke erfolgt, ist im Gesamtablauf des Recovery-Programms eher sehr, sehr kurz. Anders kann ich mir jedenfalls die Artefakte hinter den Werten bzw. die (für das Modell) unsinnigen oder ungewöhnlichen Einträge (deren Namen letztlich nur die Übersetzung der Indizes anhand der "name table" sind) nicht wirklich erklären ... auch mit "wear leveling" sollte ein sauber gelöschter NAND-Block ja keine anderen Daten mehr enthalten.
