schon wieder mein Senf zu "anderes Verhalten der 7490 beim Firmware-Update" ...
ohne gleich Freetz zu installieren?
Mach ich auch anders (daher kenne ich auch das Packen von fwmod bei einer 7490 nicht richtig), trotzdem einige Bemerkungen:
Bei der 7490 läuft der "Flashvorgang" grundsätzlich anders ab, als bei anderen Boxen. Es gibt
zwei Sätze von MTD-"Partitionen" (jeweils eine in "raw" für den Kernel und eine für das Wrapper-FS), zwischen denen nach jedem Flashvorgang umgeschaltet wird für den nächsten Start. Das heißt, nur bei jedem zweiten Flash-Vorgang wird auch dieselbe Partition im NAND geschrieben usw.
Dann kommt noch hinzu, daß das Squash-FS nicht einfach auch in "raw" in ein MTD geschrieben wird wie bei den anderen Boxen, es wird ein - im MTD schon vorhandenes - YAFFS gemounted und das SquashFS dann dort hineinkopiert, auch von dieser MTD-Partition gibt es zwei Versionen.
Ich habe noch keine Ahnung, wer da bei einem Fehler im YAFFS das entsprechend restauriert oder wie ein AVM-Firmwareupdate damit umgeht. Ich würde tippen, daß es nur bei einem AVM-Recover mit geschrieben wird, ein normales Firmware-Image enthält ja auch bei AVM nur den Kernel und das SquashFS. Aber irgendwie müssten Teile des Wrappers auch zum Kernel passen, insofern ist das noch etwas mysteriös ... allerdings läuft es wohl auf ein eher "generisches" Wrapper-FS hinaus, der Rest wird anscheinend direkt im initramfs des Kernels irgendwie behandelt. Im Extremfall wird ein YAFFS beim Mounten "formatiert", wenn also keine anderen Dateien benötigt werden (das Wrapper-FS ist ja auch im laufenden Betrieb einer 7490 unter /wrapper gemounted), könnte auch bei korruptem YAFFS das Löschen des MT-Devices und anschließendes Mounten als yaffs2 schon ausreichen für eine "Restaurierung" und die Aufnahme der SquashFS-Datei.
[EDIT]Geklärt, das YaFFS wird wirklich durch einfaches Löschen des Inhalts des MTD und anschließendes Mounten als yaffs2 neu formatiert. der gesamte Inhalt der Wrapper-Partition wird aber aus der Datei filesystem.image in einer Firmware-Image-Datei kopiert, inkl. SquashFS-File für das rootfs. Das ist dann also ein SquashFS (root) in einem SquashFS (wrapper), wobei das System in wrapper bei der Installation dann ein yaffs2 ist.[/EDIT]
Ich habe der AVM-Recovery noch nie
so genau auf die Finger gesehen bei der 7490, die "normalen" Angaben im Urlader-Environment zu den MTD-Partitionen legen eigentlich nahe, daß da die Unterschiede zu anderen Boxen eher von EVA "versteckt" werden. Ob dazu jetzt auch das Anlegen des Wrapper-FS in der Partition zählt, müsste man ggf. einfach mal ausprobieren.
Diese Vorgehensweise
kann jetzt jedenfalls m.E. dazu führen, daß Du immer in eine Version des Flashs Dein eigenes System schreibst (dann wird auch umgeschaltet) und das AVM-Recovery-Programm hinterher immer das andere System neu schreibt und dann wieder dahin umschaltet. Somit würde ein Fehler im Wrapper-YAFFS immer wieder genau bei Deinem eigenen Image dazu führen, daß z.B. das root-FS nicht gemounted werden kann. Selbst wenn EVA beim Schreiben von Kernel und SquashFS jetzt keine Rücksicht nimmt auf die gerade "aktuelle" MTD-Partition und
immer nach MTD0 und MTD1 (linux_fs_start=0) schreibt, wäre es immer noch möglich, daß dann eben Deine Versuche immer in der anderen Version (MTD2/3 und linux_fs_start=1) landen, mit genau demselben Ergebnis.
mtd0/1 in EVA dabei bitte nicht mit MTD0/1 im laufenden System verwechseln, mtd2 im Bootloader ist auch NOR und läuft unter MTD6 im FRITZ!OS. Hinter mtd0/1 im Loader dürfte sich die jeweils aktuelle Version (von EVA vermutlich anhand von linux_fs_start per MMU gemappt) der NAND-Partitionen verbergen, bis der FRITZ!OS-Kernel die Kontrolle übernimmt ... das waren sicherlich weniger Änderungen, die da am EVA-Code erforderlich waren.
Ich würde Dir vorschlagen, einmal AVM-Recovery zu machen, dann zu booten und den Wert von "linux_fs_start" zu notieren (0 oder 1). Anschließend noch einmal AVM-Recovery und wieder im Urlader-Environment nach linux_fs_start zu sehen. Wenn dort jetzt der andere Wert steht und die Box mit beiden Werten ordentlich gestartet ist, kannst Du mit einiger Wahrscheinlichkeit davon ausgehen, daß beide "filesystem"-Partitionen ein gültiges Wrapper-FS enthalten und es noch einmal mit dem eigenen Image versuchen. (Eigentlich reicht es auch aus, das neue SquashFS-File in das YAFFS in der "reserved-filesystem"-Partition mit dem richtigen Namen zu kopieren und die "linux_fs_start"-Variable umzusetzen, solange Du nicht auch den Kernel modifizieren willst.)
Ich kann mir ein primitiveres Vorgehen der EVA (immer nur MTD0/1 zu verwenden und linux_fs_start stur auf 0 zu setzen) nicht vorstellen, dann würde es vermutlich beim nächstem AVM-Update (das dann ja seinerseits wieder MTD2/3 benutzen würde) ja sofort auch wieder krachen. An das parallele Schreiben von MTD0 und MTD2 sowie MTD1 und MTD3 kann ich (geschlossen aus Symptomen) nicht so recht glauben, das müßte die EVA dann ja ohnehin intern irgendwie managen und es macht für mich wenig Sinn, bringt nur einen zusätzlichen Lösch-/Schreibzyklus und braucht mehr Zeit.
Auch das interne "Vorhalten" eines passenden YAFFS-Images, in das dann nur noch das SquashFS-File geschrieben wird, kann ich mir wegen der Abhängigkeiten (die EVA müßte dann etwas vom YAFFS wissen und bei Problemen damit auch geändert werden) eher nicht vorstellen, dazu passen auch die Timestamps der Dateien im Wrapper-FS meiner Box nicht. Da hat die eine Partition Dateien mit einem Datum vom 01.01.1970 (also praktisch ohne gültige Zeit) und die andere (AVM-Recovery-Programm für die 06.20 vom 13.08.
einmal getestet, leider genau bei linux_fs_start=1, so daß ich nicht sagen kann, ob immer nach MTD0/1 geschrieben wird oder nur weil die gerade "dran" war) solche mit dem 12.08.2014, 12:30 Uhr. Das schließt das parallele Beschreiben der Wrapper-Partitionen eigentlich genauso aus, wie das Kopieren des SquashFS-Files als Datei in das YAFFS durch EVA.
Allerdings kann dann eben unter ungünstigen Umständen das von Dir geschilderte Szenario (nur jedes zweite System funktioniert) auch bei "reiner AVM-Firmware" theoretisch auftreten, keine Ahnung, ob AVM da noch andere Vorkehrungen getroffen hat.
Wenn Du aber ohnehin immer wieder das Recovery-Programm ausführst, kannst Du das für die aktuelle Version ja gleich mitprüfen.
Es kann natürlich auch sein, daß ich mit meiner Vermutung zu den Ursachen
Deines Problems komplett daneben liege, der beschriebene Ablauf bleibt aber derselbe.
