Oder man holt sich - ganz ohne Lötarbeiten - einfach mal die "panic.log" bzw. "crash.log" aus der Box und schaut nach, wo es tatsächlich klemmt. Das geht natürlich erst dann, wenn die Box mind. einmal (nach Recovery) auch "erfolgreich abgestürzt" ist (klingt komisch, ist aber so - direkt nach dem Schreiben des TFFS-Images sind beide "Dateien" leer) - dann lädt man einfach einen eigenen Kernel samt eigener Initialisierung (wie das geht, kann man sich (für die 7490 sogar 1:1) im "first_aid"-Verzeichnis (im unten verlinkten Repo) ansehen (und sich inspirieren lassen) und schafft die Daten gleich zu Beginn per TFTP aus der Box.
Wie
das wieder geht, habe ich mal mit jemandem (iirc war es
@Massa, man müßte also den passenden Thread suchen und finden) anhand einer 7590 durchgespielt - selbst wenn der Start ein wenig anders abläuft, kann man es auch bei der 7490 anstelle des Flashens der Firmware einbauen. Die originale Datei von AVM (hier heißt sie dann "/sbin/flash_update" und steht noch im Wrapper-FS - egal, ob das jetzt "ext2" mit Dummy-Header ist oder ein SquashFS-Image) enthält dann auch schon genug Infos, wie man das Netzwerk konfigurieren könnte/müßte, damit man (per Ethernet-Kabel) die FRITZ!Box auch zu diesem frühen Zeitpunkt erreicht.
Nur setzt das - wie alles andere aber auch - den sicheren Umgang mit PC, Shell-Code und Linux voraus und auch die notwendigen "Grundkenntnisse", wie eine FRITZ!Box funktioniert und wie man wann darauf zugreifen kann. Ich habe mich nach meinem ersten Einwurf auch deshalb so zurückgehalten, weil ich den Eindruck habe, daß
@Anodos generell mit dem Thema FRITZ!Box offensichtlich das erste Mal konfrontiert ist und er (oder sie, das ist mir schnurz) mir etwas überfordert scheint (nicht als persönlichen Angriff betrachten - eher als Hinweis, sich mit den Grundlagen gründlicher vertraut zu machen, wenn das Problem weiter verfolgt werden soll und die Box nicht am Ende einfach im Müll oder bei eBay landet ... das geht dann schon dabei los, was "linux_fs_start" eigentlich ist und was es bewirkt, denn da ist "Verständnis" eben deutlich wichtiger, als erfolgreiches "Anwenden") - da wollte ich nicht auch noch mitmischen.
Vielleicht habe ich das im "Richtig recovern"-Thread tatsächlich so besch***en beschrieben - aber m.W. ist es das erste Mal, daß jemand die Abschaltung des "media sensing" so verstanden hat (zumindest wenn er/sie das dann auch hier noch anspricht), daß das nach jedem Systemstart neu zu machen wäre oder gar zu einem Zeitpunkt, wo die Box bereits im FTP-Modus steht und wartet - zumindest sieht das ja in dem Screenshot von "cmd" oben so aus, als wäre das "netsh" unmittelbar vor dem "ftp" eingegeben. Spätestens aus dem Kontext meiner Beschreibung dazu sollte sich ja ergeben, daß man das eben einmal umschaltet und dann ist's gut - bis man sein Problem gelöst hat (das besteht in diesem Kontext dann in der erfolgreichen Ausführung des Recovery-Programms) und dann kann/sollte man das "media sensing" auch wieder aktivieren, weil der PC ansonsten seinen DHCP-Client nicht anwirft, wenn ein Kabel (frisch) eingesteckt wird (was beim Start der FRITZ!Box auch wieder der Fall wäre bzw. denselben Effekt hat).
Aber auch die Ambitionen, den DHCP-Service zu stoppen (#22 und #25), machen auf mich nicht den Eindruck (auch wieder i.V.m. #20, denn mir fehlt jede Idee, warum man den Icon-Cache unter Windows löschen sollte für einen Neustart), daß da jemand "sattelfest" ist und dann bin ich wohl deutlich der falsche "Erklärer". Letztlich verstehe ich nicht mal, warum man hier den PC überhaupt neu starten will (außer ggf. mal ganz am Beginn der Aktion) ... für das Ein- oder Ausschalten des "media sensing" ist das - im Gegensatz zu früheren Windows-Versionen, wo es kein "netsh" gab (zumindest nicht mit diesem Funktionsumfang) und man solche Änderungen über die Registry ausführen mußte - überhaupt nicht erforderlich, das wirkt "umgehend" und ohne Neustart.
Wobei dann auch noch auffällt, daß die verwendete Windows-Version (wenn ich es nicht doch überlesen habe) bisher nirgendwo explizit erwähnt wurde - auch wenn man aus den Screenshots und dem "flat design" der Titelleisten der Fenster auf Windows 10 "schließen" kann und das Quittieren des "netsh" mit "Ok." ein Zeichen dafür ist (und das stand irgendwo auch in diesem Thread hier), daß es eine passende (neuere) Windows-Version sein sollte.
Es wird in einem Beitrag auch beschrieben, daß die "Anzeige" für das Netzwerk unter Windows "ständig" wechselt (#39) - darauf ging (in den letzten Beiträgen) aber niemand ein. Erstens zeigt es wieder die "Überforderung" (zumindest in meinen Augen), denn mit der Angabe "ständig" kann man natürlich nur sehr wenig anfangen und zweitens lese ich da (vielleicht ja auch nur in meiner Einbildung), daß die Box für eine gewisse Zeit
durchaus funktioniert (und auch erreichbar sein sollte - aber das steht auf einem anderen Blatt) ... denn wenn man mal die "Meldungen" analysiert, stellt man ja fest, daß das "Netzwerkkabel wurde entfernt" zu erwarten ist, wenn die - direkt verbundene - FRITZ!Box nicht am Strom hängt oder wenn sie sich gerade in einem Zustand befindet (ein solcher tritt z.B. unmittelbar nach EVA wieder auf, bis dann nach ca. 20 Sekunden das Netzwerk (bzw. der interne Switch) wieder aktiviert wurde), in dem der interne Switch "abgeschaltet" wurde. Das ist am Ende sogar eine sehr sinnvolle Maßnahme (keine Ahnung, ob das "Zufall" ist oder von AVM absichtlich so gestaltet wurde), weil bei eingeschaltetem, aber unkonfiguriertem Switch eben alle Ports miteinander verbunden sind und damit dann - solange der Switch nicht neu konfiguriert wurde - auch "Grenzen" im Netzwerk überwunden werden können, die bei "voll gestarteter Box" bestehen würden.
Die Frage, die sich dann stellt, ist es doch, was hier das "ständig" sein soll bzw. welche Zeiten zwischen solchen Wechseln vergehen. Ein "nicht identifiziertes Netzwerk" weist ja - wenn alle Einstellungen passen und da wurde (für meinen Geschmack) schon viel zu viel verstellt - üblicherweise darauf hin, daß der entsprechende Netzwerk-Adapter unter Windows 10 eine Adresse erhalten hat (hier sollte man "media sensing" dann auch bereits wieder eingeschaltet haben) und die kann er eigentlich nur kriegen (wenn das nicht - fälschlicher- bzw. zumindest unnützerweise - immer noch eine statische ist), wenn da ein DHCP-Server auf der Box arbeitet. Zumindest sollte man DAS eben erst einmal abklären - eine Diagnose anhand der Feststellung "Ich kann das GUI nicht erreichen." ist wenig sinnvoll, weil es dafür letztlich sooo viele unterschiedliche Ursachen geben kann, daß man sich dabei zwangsweise "verlaufen" muß.
Also sollte man hier (und nun einfach erst einmal ohne weitere Anwendungen eines Recovery-Programms, weil kaum zu erwarten steht, daß sich dessen Resultate (so man es ein einziges Mal "vernünftig" angewendet hat) durch ständige Wiederholungen ändern werden) erst einmal klären, was denn eigentlich tatsächlich in der Zeit geschieht, in der die Box ja - der Beschreibung nach - auch arbeitet ... jeder weitere Schritt nach 20-30 Sekunden (ab EVA-Ende) sollte auch mit einem (per Ethernet-Kabel) erreichbaren Netzwerk in der FRITZ!Box aufwarten können und - ebenfalls wieder nach den abgegebenen Beschreibungen (die hinsichtlich der "Blinkdauer" ja sehr ausführlich und damit gut nachvollziehbar sind - im Gegensatz zu manchen anderen Threads) - die Netzwerk-Ports scheinen ja tatsächlich i.O. zu sein.
Wobei man letzteres auch problemlos noch einmal explizit testen kann ... man hält die Box in EVA an und probiert (bei laufendem "ping" vom PC auf die IP-Adresse der Box) die Ports mit dem Ethernet-Kabel durch - bei der 7490 mit dem VR9-Switch gibt es den "WAN"-Port mit der "Sonderrolle" nicht und damit sollte die Box in diesem (rudimentären) Zustand auf allen vier Ports auch erreichbar sein. Ist das der Fall, kann man einen PHY-Schaden schon mal
definitiv ausschließen (mit ganz, ganz geringer Restwahrscheinlichkeit, die ggf. im verwendeten Ethernet-Mode zu suchen wäre) - dann braucht es (erst einmal) auch keinen weiteren Test mit einer älteren Firmware, wo ein solcher Defekt noch toleranter behandelt wurde.
Das Windows-Netzwerk mit seinen "Anzeigen" ist jedenfalls ein sehr unzuverlässiges "Meßinstrument", was das Funktionieren einer Ethernet-Verbindung anbelangt - hier muß man sich also auf die Kommandozeile begeben und mit den passenden Werkzeugen ("ipconfig /all", "arp -a" und "ping <ip>") einen "zeitlichen Verlauf" ermitteln - und den dann am besten genauso ausführlich beschreiben, wie die Blinkreihenfolge der LEDs (wobei mir dabei auch die WLAN-LED irgendwie "fehlt" - zumindest kann man am Beginn von deren Blinken erkennen, ab wann das Ethernet-Interface der FRITZ!Box funktionieren sollte -> weil da das LAN bereits gestartet wurde).
Ein weiterer Ansatzpunkt wäre es, wenn man den Systemstart anhand von "Markern" verfolgt - welche man da verwenden könnte (von "firmware_info" bis "ptest"), habe ich mehrfach schon beschrieben. Beim Systemstart werden eben ein paar Environment-Variablen ausgelesen und gelöscht bzw. neu geschrieben - und den Inhalt des Environments kann man ja über EVA auch auslesen (bei dieser Box würde ich zumindest Wetten darauf abschließen). Damit kann man (wenn man da beim Start entsprechende eigene Eintragungen vorgenommen hat) auch feststellen, wie weit die Firmware beim Initialisieren der Box "in etwa" kommt (die "S42-ptest", wo dann die "ptest"-Variable erst gelöscht wird, liegt praktisch unmittelbar vor dem Start des Netzwerks in der "E46-net") und daraus zumindest mal ein paar (plausible) Hypothesen aufstellen, wo es am Ende klemmen könnte.
Das wäre zumindest eine weitere Alternative, die auch mit (in meinen Augen) wenig Aufwand verbunden ist und wenn man hier im Board mal etwas sucht, findet man garantiert auch ein paar "Startprotokolle" einer FRITZ!Box 7490, aus denen man dann - wenn auch nur ungefähr - ableiten kann, wo sich eine FRITZ!Box zu dem Zeitpunkt gerade befinden sollte, an dem sie - der Beschreibung nach - dann neu bootet.
Hier erlaube ich mir auch noch einmal die Bemerkung, daß die "Blinkreihenfolge" in #1 (und später auch noch ein paar Mal) gut und ausführlich "beschrieben" wurde - aber eine kleine "Zeitachse", wann welche LED mit der Signalisierung beginnt, wäre übersichtlicher ... zumindest was die "Gesamtdauer" des Vorgangs angeht. Hier muß man erst selbst "zusammenrechnen" und eine Beschreibung " blinkt dann noch einmal viermal für ca. 7 sec" ist auch durchaus "mißverständlich", weil die 7 Sekunden sicherlich die gesamte Dauer des Blinkens beschreiben sollen und nicht die Periode eines einzelnen, kompletten "Zyklus" und somit die Frequenz des Blinkens, worin sich ebenfalls noch eine Information verbirgt (wo also "schnelles Blinken" und "langsames Blinken" auch eine unterschiedliche Aussage haben und es sogar mehr als diese zwei Unterscheidungen - langsam vs. schnell - gibt).
Mein Tipp für das Erstellen solcher "Beschreibungen": Macht mit dem Smartphone ein Video eines solchen Startvorgangs und seht Euch dieses selbst mehrmals an, während ihr die Beschreibung "zu Papier" bringt - da kann man wunderbar auch die "on/off"-Zeiten einer LED beim Blinken ablesen (an der Zeitleiste des Videos) und - wenn alle Stränge reißen bzw. als "Zusatzinformation" - man kann dann das Video auch noch irgendwo bereitstellen (ggf. auch geschnitten) und hier verlinken - wobei das eine Beschreibung nicht ersetzen kann und mancher (u.a. auch ich) auch nicht begeistert ist, wenn er das quasi als "Guck gefälligst selbst."
anstelle einer Beschreibung vorgesetzt bekommt.
====================================================================
Wobei die sinnvollste (und erfolgversprechendste) Lösung natürlich weiterhin die wäre, daß man sich ein eigenes, passendes Image bastelt (und zwar nur mit Kernel und FS), das einem entweder die Daten aus der Box exportiert oder gleich noch einen Telnet-Daemon (zur genaueren Untersuchung der Flash-Partitionen und ihres Inhalts) bereitstellt - also letztlich "Forensik" betreibt und "von außen" versucht, dem Problem auf die Spur zu kommen. Das ist zwar auch die Lösung, welche die meisten Kenntnisse erfordert (und damit sicherlich auch den größten zeitlichen Aufwand) - aber dafür führt sie (mit hoher Wahrscheinlichkeit) auch zum Ziel ... selbst wenn das zunächst mal nur "Diagnose" lautet und nicht zwingend auch "funktionierende Box" bedeutet (je nach der Ursache des Problems).
WinError -3 ist aber bei dieser alten Recovery-Version noch kein Hinderungsgrund, jetzt schon aufzugeben. 
