[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Wie gesagt, die Erkenntnisse entwickeln sich ja weiter ... vieles, was dort noch unklar war (z.B. wie das Flashen aus dem laufenden System dann läuft), ist heute geklärt.

@KiRKman:
Es wird definitiv im Laufe der Woche ... das mksquashfs4 läuft schon, nur das modfs muß eben erst einmal zur Unterscheidung zwischen SquashFS4 und SquashFS3 "aufgebohrt" werden; das muß ja alles noch von 06.25 im "update"-Modus erfolgen und auch wenn das gepackte Image "von außen" gut aussieht, ist die wahre Nagelprobe das Mounten des neu gepackten Images unter dem neuen Kernel und ich habe den immer noch nicht aktiviert.

So, eine neue Version von modfs ist verfügbar, sie unterstützt jetzt auch den 06.35er-Labor-Zweig.

Der zum Bauen des mksquashfs-Binaries für die Ausführung auf der FRITZ!Box notwendige Patch steht unter der URL

http://yourfritz.de/7490/avm_be_xz_mksquashfs_target.patch

zum Download zur Verfügung. Dieser Patch verträgt sich nicht mit meinem Patch für unsquashfs, es ist also ein "frisches Base-Directory" mit der Version 4.3 der squashfs-tools erforderlich. Der Patch steht da vorerst auch nur, um der GPLv2 zu entsprechen, denn das modfs-Archiv enthält ein mksquashfs4-Binary und damit ist das Veröffentlichen des Quellcodes erforderlich. Nachdem das nur ein Patch gegen das Original ist, braucht es keine weiteren Skript-Files o.ä. zum Erstellen dieses Binaries, das ist "normales Vorgehen", nachdem der Patch angewandt wurde.

Die Integration beider Patches in ein gemeinsames Paket (ggf. auch gleich noch in ein gemeinsames Paket für einen LE-Build-Host und die VR9-Targets (BE)) wird noch einiges an Aufwand erfordern, ich stand jetzt vor der Entscheidung, das bisher Funktionierende endlich mal zu veröffentlichen oder weiter an Optimierungen zu basteln, die bestimmt noch locker zwei Wochen brauchen.

In diesem Kontext ist auch der "unvollständige Boot-Manager" zu sehen. Wenn man in einer Box mit unterschiedlichen Kernel-Versionen in den beiden Partitionen auf der Reboot-Seite die Auswahl zwischen beiden Systemen aktiviert hat (ist ja ein optionaler Patch), dann können diese Systeme wechselseitig die Versionsnummer des jeweils anderen nicht auslesen, das endet im Moment im besten Falle (wenn schon die aktuelle Version verwendet wird) mit "unknown" für die variablen Texte ... solange da aber eine ältere Version von "guibootmanager" im Dateisystem ist, liefert die nur einem "mount"-Fehler. Da dort dann das Ermitteln der Versionen von "mount" auf "unsquashfs" umgestellt werden müßte und das alles andere als "responsive" wäre, verzichte ich auf diese Spielchen und nehme dieses "Problem" in Kauf. So muß man sich halt merken, welche Version in der anderen Partition liegt, das Umschalten funktioniert ja trotzdem. Das Problem der unterschiedlichen Einstellungen (beim Wechsel von 06.35 auf 06.25 relevant) ist damit aber auch noch nicht gelöst, das könnte dann nur der "richtige" bootmanager und der kennt im Moment die Versionsgeschichte beim Mounten auch noch nicht. Die Sicherung von Einstellungen (liegen ja dann im yaffs2 und nicht im SquashFS) funktioniert, auch das Umschalten ... nur das Auslesen von Versionen klappt eben wechselseitig ebenfalls nicht zwischen 06.25 und 06.35 - wie beim guibootmanager auch.

Ansonsten funktionieren die wichtigsten "mitgelieferten" modscripts auch bei der neuen Version problemlos bei mir, sowohl Telnet als auch "guibootmanager" (Einschränkung s.o.) und "debug.cfg/rc.user" klappten auf Anhieb, nachdem erst einmal das Format des erzeugten Dateisystems stimmte.

Wichtig wäre es noch, daß man beim Download beachtet, daß die vorherige Version unter der URL

http://yourfritz.de/modfs.tgz

weiterhin zur Verfügung steht, die neue Version ist nur über die URLs

http://yourfritz.de/modfs_with_0635.tgz oder
http://yourfritz.de/7490/modfs.tgz

zu erreichen.

Wenn ich jetzt nicht beim Deployment etwas durcheinander gebracht habe, sollte es klappen ... über Rückmeldungen (gerade für 06.35 natürlich) würde ich mich freuen, auch über positive - man kann nach solchen Änderungen nicht alles komplett erneut testen.

Für eine "Machbarkeitsstudie" ist das Ganze inzwischen ohnehin zu komplex geworden ... das muß weiter modularisiert werden, damit da auch so etwas wie "unit tests" möglich werden. Ob "ash" dafür die richtige Basis ist? In mir baut sich immer mehr der Gedanke an eine Umstellung auf Lua auf ... das ist ebenfalls auf der Box vorhanden (wichtig für den "ersten Kontakt"), kann objektorientiert genutzt werden (gut zu modularisieren) und wäre ein Schritt hin zu einer "graphischen" Lösung, wenn man die Ausgabe entsprechend flexibel gestaltet.

Auch ... habe ich ja schon genug zu geschrieben.

Aber das AVM-Interface fluktuiert ohnehin zu stark, als daß man sich da "anhängen" sollte - da ist ein eigenes Interface (unter Nutzung von AVM-APIs, u.a. zum AAA) dann schlauer (meines Erachtens).

Lua "kann" ja auch STDIO und mir geht es in erster Linie darum, mit möglichst wenigen zusätzlichen Komponenten (für modfs - was der Benutzer installieren will, interessiert mich nicht) auszukommen. Da ist dann Lua die einzige "Programmiersprache", die auf der Box vorhanden ist. Da braucht man weder Perl, noch PHP oder Python nachinstallieren, damit überhaupt modfs erst einmal läuft.

In Shell-Code sind nur eben "unit tests" (das sind kleine Tests für die korrekte Funktion und Fehlerbehandlung einzelner Code-Teile) "a pain in the ass" und für einen wartbaren Code braucht es genau so eine Zerlegung in kleinere Einheiten (geht bei Shell auch, aber mit einem riesigen Aufwand beim Austausch von Variableninhalten zwischen diesen Einheiten), die jede für sich ein genau definiertes Verhalten zeigen. Wenn man dann irgendwo ändert, muß man nicht den gesamten Code erneut testen ... der Theorie nach funktioniert so ein Modul dann, wenn es diese Unit-Tests besteht. Das macht schon einen gewaltigen Unterschied ... selbst wenn man den anderen Aspekt der Modularisierung (das wäre die Wiederverwendbarkeit) gar nicht braucht oder haben will.

Entweder

- auf eine vorher installierte Version vor 06.25 "zurückschalten" oder

- Recovery auf eine Version mit Telnet oder

- Pseudo-Image für den Telnet-Start unter 06.35 verwenden (vorher das modfs-Paket nach /var/media/ftp schieben, sonst wird es eng mit dem Laden aus dem Internet)

Das wären jetzt so die ersten drei Möglichkeiten, die mir einfallen, wobei ich die in der Reihenfolge 3, 1, 2 probieren würde ... in diesem Sinne: It's tool time and pimping your Binford 7490 FRITZ!Box to get more power is even home improvement.

Das Thema "Pseudo-Image für Telnet-Start unter 06.35" hatten wir gerade erst irgendwo ...

Das hört sich eher so an, als wenn ich doch bei Auschecken der Version durcheinander gekommen bin - das kam mir gleich so merkwürdig vor, was da beim Packen passierte (daher auch das "Deployment-Problem").

Ich schaue mir das nachher gleich noch einmal an ... wobei ich noch ein Problem gesehen habe, was die Versionen vor 06.29 wohl noch nicht hatten.

Das liest sich ja so, als ob das head-Applet in der 06.29 nicht enthalten ist - das habe ich nie versucht, die 06.29 war bei mir nie Thema - und so wie sich der Update-Prozess darstellt, kann ich mir auch vorstellen, daß dort losetup ebenfalls nicht vorhanden ist.

Das könnte dann auch erklären, warum AVM den relativ komplizierten Weg über dd wählt, um das ext2-Image zu mounten ... wenn in der 06.29 wirklich kein losetup mehr enthalten ist, haben sie sich dieses Problem tatsächlich erst nach der 06.24 (von dort bin ich bei allen Tests vorgegangen) selbst "eingebrockt".

Bei einem Fehler bleiben auch (hoffentlich) keine Dateien liegen, die werden alle wieder ordentlich abgeräumt - das hilft Dir also nicht wirklich weiter, außer Du willst es "richtig zu Fuß" machen, dann kannst Du wenigstens die Programme zum Entpacken und Packen des SquashFS4 verwenden.

Ich werfe nachher mal einen Blick in die 06.29, was da sonst noch so an Veränderungen in Bezug auf die verfügbaren Programme passiert ist. Ob Dir die Empfehlung, von der 06.24 aus das Update - genau so, wie oben von Dir versucht - zu machen, weiterhilft, mußt Du selbst entscheiden.

Auch habe ich den Eindruck, daß bei der bereitgestellten Version (s.o. - Problem beim Auschecken) das "normale Modifizieren" innerhalb der 06.35 wieder fehlt, die Funktion zum Suchen des Firmware-Images in vorhandenen Mount-Points sieht komisch aus und beim Modifizieren des vorhandenen root-FS fehlt wohl auch beim Auspacken die Abfrage der Version und die Auswahl des richtigen "unsquashfs"-Programms.

Das ist genau der Zweig, den ich auch erst einbauen/testen konnte, als ich schon zum Test auf der 06.35 war (vorher ist ja die Änderung innerhalb der Version schlecht zu testen) und irgendwie sind diese Änderungen wahrscheinlich versehentlich von mir ebenfalls überschrieben worden (durch falsches Merge beim Checkout), als ich Änderungen am SquashFS4-Patch zurückrollen wollte.

Damit taugt das nun wohl nur noch zum Update von der 06.24 (von der 06.25 aus habe ich auch nicht getestet, wenn da weitere Applets (losetup) schon fehlen, wird das auch nicht funktionieren) auf die 06.35 - ob das jemandem etwas nutzt, weiß ich nicht.

Glücklicherweise kam mir das dann gleich so komisch vor, daß ich es unter einem anderen Namen bzw. Pfad bereitgestellt habe und damit wenigsten die vorherige Version noch vorhanden ist, wenn jemand die 06.25 modifizieren will. Das Update von der 06.24 (Release) auf die 06.25-RC (mit Einbau von Telnet) funktioniert ja auch - mit der Vorgängerversion -, genauso wie die Modifikation der 06.25 von der 06.25 aus (da sollte dann auch noch "head" vorhanden sein, denn dieser "Fehler" ist neu).

Ich schaue mir das wie gesagt noch einmal an ... komme aber erst gegen Abend dazu. Ob ich am Ende dann noch ein eigene Busybox in das Paket packe oder das Verhalten von fehlenden Applets nachbilde oder auf die 06.29 komplett "verzichte" (ist ja nur eine "Episode" bei AVM, da lohnt sich der Aufwand eigentlich fast nicht), kann ich noch nicht sagen.