Dein Ernst? Warum ist das Erstellen eines Screenshots so viel einfacher, als den entsprechenden Text aus der Support-Datei zu KOPIEREN und hier als Text einzustellen, wobei man dann sogar das noch lesen kann, was VOR der ersten sichtbaren Zeile steht? Warum müssen wir uns die Augen verderben beim Versuch, das irgendwie in diesem "Screenshot" zu erkennen?
Egal ... was halt fehlt, sind der Annex (der dürfte keine Rolle spielen) und tatsächlich die Variable
linux_fs_start. Nun ist zwar an den meisten Stellen dafür der Standardwert
0 zu finden, aber erst im weiteren Verlauf der Support-Datei dürfte man dann sehen, ob das System tatsächlich auch aus den Partitionen
mtd0 und
mtd1 gestartet wurde.
Merkwürdig ist in diesem Zusammenhang die Tatsache, daß der Wert bei
memsize eher darauf hindeutet, daß das System tatsächlich aus dem RAM läuft - ansonsten wäre ein Wert von
0x10000000 zu erwarten bei einem Speicherausbau von 256 MB bei einer 7490.
Bei den VR9-Boxen erfolgt das selbständige Installieren in den NAND-Flash in der Datei
/sbin/flash_update, die man im Image der Wrapper-Partition findet. Tritt dort beim Flashen ein Fehler auf, wird das zwar auf der seriellen Console protokolliert, die Update-LED (das Blinken der Info-LED) wieder ausgeschaltet und das Skript über ein
exit <rc> verlassen. Da in der
/etc/inittab, aus der das Flashen gestartet wird, jedoch nicht nach dem Exit-Code geschaut wird (bzw. werden kann), läuft die Box auch nach einem Problem beim Flashen einfach weiter - dann halt komplett aus dem RAM (sieht man spätestens in der Ausgabe von
/proc/mtd in den Supportdaten) und mit entsprechend verringerter Größe des verfügbaren Hauptspeichers (DA könnte man das dann auch noch sehen).
Angesichts dessen, daß offenbar der Bootloader noch in Ordnung ist und auch das Speichern von Einstellungen in den TFFS-Partitionen wohl noch funktioniert, würde ich hier inzwischen eher auf Probleme mit dem NAND-Flash tippen, der wiederum tatsächlich nur ersetzt werden müßte, denn alle weiteren Informationen stehen im SPI-Flash.
Aber das ist auch nur geraten im Blindflug, denn leider stehen all die anderen wichtigen Informationen dazu in den auf das Urlader-Environment folgenden Zeilen der Support-Daten - da KÖNNTE (unmittelbar nach dem Start des FRITZ!OS) sogar noch die Ausgabe vom Flash-Versuch auftauchen, sofern zu diesem Zeitpunkt die (Console-)Ausgabe noch in die Kernel-Messages gedoppelt wird.
Sollte sich irgendwann mal die übermäßige Zurückhaltung bei der Preisgabe von Support-Daten der Box legen und die tatsächlich mal VOLLSTÄNDIG hier als Anhang zur Verfügung stehen (für das Maskieren der allermeisten "kritischen" Daten sorgt AVM mittlerweile schon selbst und eine "frische" Box sollte ja auch noch keine benutzerspezifischen Daten enthalten), kann man ja noch einmal einen Blick riskieren.
Für diejenigen, die sich selbst einen Eindruck verschaffen wollen, wie der Flash-Vorgang abläuft und woran er dann wie scheitern kann, hänge ich mal die
/wrapper/sbin/flash_update aus der 07.56-Release ran (die könnte sich auch jeder selbst dort extrahieren - dennoch gilt für diese Datei das Urheberrecht von AVM(!) und ich zeige sie hier nur, damit man das auch später, wenn diese Datei entfallen sollte in der Firmware, noch nachvollziehen kann).
Die
/etc/inittab, aus der heraus das Skript gestartet wird, sieht so aus:
Rich (BBCode):
null::sysinit:/bin/mount -t squashfs /filesystem_core.squashfs /core -o loop
null::sysinit:/bin/mount /dev /core/dev -o bind
null::sysinit:/sbin/pivot_root /core/ /core/wrapper/
null::sysinit:/wrapper/sbin/flash_update
::sysinit:/etc/boot.d/1
ttyS0::askfirst:-/bin/sh
ttyS0::shutdown:/bin/sh -c /var/post_install
::shutdown:/bin/kill -- -1
::shutdown:/bin/sleep 5
und die Zuordnung der Partitionen im NAND bzw. das Initialisieren von MTDs erfolgt bereits bei der Kernel-Initialisierung, wie man in den von AVM bereitgestellten OSS-Paketen nachlesen kann.
Daher sollte es auch bei defektem NAND eigentlich reichen, diesen passend zu ersetzen und dann einfach noch einmal einen Versuch des Flashens (notfalls auch mit dem AVM-Recovery-Programm, obwohl das eher der Schmiedehammer für die Reparatur einer Luxusuhr wäre) zu starten.
