Das Image bei der 7390 muß wieder anders zusammengebaut werden (Kernel + Filesystem in einem) ... auch wenn es Freetz letztlich genauso macht oder meinetwegen auch vormacht, bleibt das für mich (auch wegen der sukzessiven Abschaffung dieser Modelle bei mir) keine wirkliche Option.
Klar kann man mit einem passenden "Pseudo-Update" sogar wieder ein Firmware-Update von einem beliebigen direkt im NAND-FS (also unterhalb von /var/media/ftp) abgelegten Image ausführen (muß man halt ins tmpfs schaffen, habe ich sogar mal gebaut mit Auswahl eines Images aus mehreren dort abgelegten) - aber die Vorbereitungsarbeiten bleiben trotzdem.
Bei den NAND-Modellen macht das für mich auch nur deshalb Sinn, weil es eben (schon heute und künftig zunehmend) Leute gibt, die gar keinen PC (ob mit Windows oder Linux) mehr haben. Die werden dann aber nicht mit alten FRITZ!Boxen starten ... und wer eine alte FRITZ!Box hat, hat auch einen PC (oder kennt jemanden, der einen hat :mrgreen
und dann ist Freetz (bzw. genauer fwmod, denn Freetz muß man ja nicht nehmen) wieder das einfachere Werkzeug.
Aber die Anpassungen bei "modfs", damit das eben nicht sofort in die andere Partition geschafft wird, sind wirklich minimal ... ansonsten braucht es noch die andere Variante der SquashFS-Tools für Version 3 mit LZMA-Kompression, ist aber auch kein Problem. EDIT: Ich hatte glaube ich sogar mal eine Variante von unsquashfs in einem Freetz-Ticket, die ohne das Aufteilen der einen Image-Datei in den Kernel und das Dateisystem beim Entpacken auskam, damit da nicht der doppelte Platzverbrauch im tmpfs beim Umpacken entsteht, wenn man erst das SquashFS-Image vom Kernel trennen muß - das Zusammensetzen (bzw. das Überschreiben des Dateisystems) nach dem Packen ging dann auch direkt mit "dd" wieder ganz gut, deshalb brauchte es keine gesonderte Variante beim Packen, wo man den Kernel gleich noch vor dem Dateisystem ausgibt bzw. man braucht den vorhandenen Kernel im Flash gar nicht erst zu überschreiben, wenn der zum neuen Dateisystem paßt und kann sich auf das SquashFS-Image beschränken.
Ich will mir bloß die Probleme nicht antun, die ggf. bei den NOR-Boxen auch auftreten können (wie bei den NAND-Boxen hier ja nachzulesen) und dort dann aber fast zwangsläufig zu Recovery führen würden. Das macht ggf. dann auch den "Ruf" von modfs unnötig kaputt und dafür reichen dann schon 5-10 User, die negative Erfahrungen damit machen (auch wenn es am Ende vielleicht nicht einmal am modfs liegt), damit es da "schlechte Presse" gibt und die Leute eher vor der Verwendung zurückschrecken als sich darauf einzulassen. Das, was bei den NAND-Boxen noch mit einer ordentlichen "Fehlermeldung" im Terminal endet und dann die Box noch gar nicht verändert hat, ist ab einem bestimmten Punkt bei den NOR-Modellen nicht mehr umkehrbar.
Auf der anderen Seite habe ich auch etwas "Angst", daß es dann mehr Leute gibt, die ihre NOR-Boxen so behandeln, daß diese nicht mehr richtig starten und sich mit dem Problem dann an AVM wenden anstatt an uns hier. Daher sehe ich die älteren Modelle wie die 7270v-irgendwas wieder unkritischer als eine 7390 (dabei fehlt dort wieder der NAND-Flash an sich), weil die mittlerweile aus der fünfjährigen AVM-Garantie (weitestgehend) herausfallen dürften, was bei der 7390 noch lange dauern wird. Wenn die "Hemmschwelle" des Nicht-Verstehens, was da eigentlich passiert, so weit sinkt, daß sich das am Ende jeder zutraut, der noch nicht einmal ein ordentliches Recovery hinbekommt (angefangen bei der "Security-Suite" auf dem PC), dann steigt m.E. die Anzahl der "kaputten" Boxen ... hier hat eben Freetz mit der recht hohen Hürde beim Einstieg (sowohl was Kenntnisse/Fertigkeiten als auch Zeitaufwand angeht) eine dämpfende Wirkung auf allzu enthusiastische "Spielkinder". Bei den NAND-Modellen kann man wieder weniger "kaputt machen" bzw. es schneller/einfacher reparieren.
Zwar ist die Zerlegung in zwei Teilschritte (s. Dein Vorschlag) tatsächlich denkbar, aber ich habe auch keine "Angst" vorm Flashen oder finde das wirklich "kompliziert" (es braucht nur einen Dateinamen, eine Startadresse und eine Längenangabe, wenn man will noch eine passende CRC-Summe am Ende, wobei selbst die nicht sein muß und schon kann man einen Kernel-Treiber laden, der das ins Flash schreibt und die Box dann neu startet). Es ist halt etwas zu rechnen für die Größen und Startadressen beim Flashen, aber das ist auch nur ein sekundäres Problem.
Der entscheidende Punkt ist nach wie vor (auch bei dem, was ich selbst bei der 7390 regelmäßig ändere, das läuft i.d.R. auf das leicht abgewandelte Aktivieren von "YourFritz" (hier halt im NAND-FS abgelegt anstelle von /wrapper/custom) über die Hooks wie bei der 7490 hinaus, habe ich weiter vorne mal angetextet als es um YourFritz als Framework ging), daß es auf den NOR-Modellen echt eng zugeht und da ohnehin nur minimale Skript-Änderungen ohne das Hinzufügen irgendwelcher Binärdateien sinnvoll sind (allerdings kann man den Standard-Inhalt für den NAND-Flash entsorgen, das schafft ein wenig Platz). Aber schon das Ersetzen der Busybox durch eine besser ausgestattete wird ohne das Entfernen anderer Teile zu einer diffizilen Angelegenheit, je nachdem, wie es um den freien Platz bestellt ist.
Allerdings würde natürlich das Reaktivieren von Telnet funktionieren oder das Starten von Kommandos aus der rc.user oder das Hinzufügen des alten nmbd ... aber wer das einmal unter Linux mit einer angepaßten "fwmod_custom" fertig präpariert hat, der braucht das genau ein einziges Mal pro neuer Firmware-Version. Alles andere, was man bei den NAND-Modellen so machen kann mit iterativen Änderungen oder dem schnellen Wechsel zwischen zwei Versionen, fällt dort ohnehin flach ... das macht es in meinen Augen so uninteressant. Es ist natürlich kein Problem, ein Paket aus ein paar Skripten und den notwendigen Binaries für x86-Rechner zu schnüren, mit dem man auch ohne komplette Freetz-Toolchain die Skripte einer AVM-Firmware bei NOR-Boxen ändern kann ... aber auch im Freetz-Projekt steht diese Idee irgendwo auf den hinteren ToDo-Plätzen, weil es wohl keinen Bedarf gibt oder man ihn nicht "befriedigen"
will. Die Leute mit dem Bedarf an "kleinen Änderungen" sind halt dort nicht das richtige Publikum ...
Daß ich selbst auch nicht allzu viel von Telnet-Zugriff halte (selbst im LAN), ist ja kein großes Geheimnis ... daß man es trotzdem auch mit den von mir bereitgestellten "Werkzeugen" wieder aktivieren kann, liegt am Ende nur daran, daß es eben der entscheidende Punkt ist, den die meisten von früher her kennen und den sie wieder haben wollen. Schon die SIAB-Installation "verträgt" sich wieder besser mit meinem Sicherheitsverständnis in Bezug auf den Zugriff auf das Gerät ... dafür "beißt" sie sich mit meinem Verständnis zur Verwendung von fremden Binärdateien. Da den schmalen Grat zu treffen, ist nicht so einfach - das muß ich mit der Einbeziehung von NOR-Modellen in meine Überlegungen nicht noch weiter verkomplizieren.
Von der Idee für die NOR-Boxen (vor > 1 Jahr war das wirklich noch auf dem Zettel) bin ich eigentlich wirklich weg ...
