Nein, es wird kein "klassisches" "modfs" für GRX-Boxen geben (jedenfalls nicht von mir), auch nicht für Vx180-, Puma6- oder IPQ-SoCs.
Das heißt nicht, daß ich die komplett vergesse oder vergessen habe ... das Vorgehen, was "modfs" benutzt, macht auf diesen Boxen keinen rechten Sinn - dabei bleibe ich.
Am Ende lassen sich alle Modifikationen, die ich bisher für die Boxen veröffentlicht habe, auf die folgenden, grundlegenden Schritte reduzieren und das auch noch unabhängig davon, auf welchem System (FRITZ!Box oder nicht) sie ausgeführt werden:
- Erkennen des Format und Ermitteln der Parameter für den späteren "Zusammenbau"
- Zerlegen der Firmware in die verschiedenen Teile (Kernel, Dateisystem (entpackt natürlich) und ggf. "Wrapper")
- Vornehmen von Änderungen
- Zusammenpacken der neuen Firmware (je nach Modell)
- Installation der Änderungen
Nur der Schritt 3 mit den jeweiligen Änderungen unterscheidet sich bei den verschiedenen Anwendungsfällen - der Rest rundherum ist praktisch immer derselbe.
Wenn die Schritte 1, 2, 4 und 5 wirklich "fertig" sind bzw. einen Stand erreicht haben, den ich mit anderen teilen möchte, werden die natürlich auch veröffentlicht - nur wird das dann mit "modfs" nicht länger etwas zu tun haben und dieses "Projekt" wird dann leise sterben ... weil das andere alles das ebenfalls leisten kann, was bisher in "modfs" alles in einem großen Klumpen zusammengefaßt wurde.
========================================================================
Nur gibt es immer wieder ein paar Überraschungen, was das Auftauchen neuer Formate bei AVM angeht - das geht bei der Erkennung, welche C-Library da eigentlich verwendet wird, schon los und zieht sich über die Firmware für Repeater (hier konkret der 546E, wo das Entpacken bzw. automatische Erkennen aller Parameter derzeit noch scheitert, wie ich erst vor ein paar Tagen bemerkt habe) bis hin zur neuesten Form bei der 7490 mit der akt. Inhouse-Version. Hier gibt es immer dann, wenn ich der Ansicht bin, es wäre langsam fertig, wieder neue Überraschungen - bis hin zu fehlenden Kommandos auf einer Plattform, denn bei AVM gibt es in der Firmware (und damit auf der Plattform "FRITZ!Box") nicht mal ein "strings"-Kommando in der BusyBox.
Das ist also tatsächlich alles nicht so einfach und ich habe mich - anhand einiger Erfahrungen, die ich zuvor machen mußte - auch dazu entschlossen, das nicht mehr "stückweise" zu veröffentlichen, wenn ich denke, daß ein Teil jetzt "fertig" wäre. Erstens gibt es immer wieder Änderungen, weil eben auch AVM die Entwicklung nicht einstellt und zweitens will ich das erst dann wirklich freigeben, wenn es halbwegs "rund" läuft und andere damit auch etwas anzufangen wissen, denn "Meckereien" gibt und gab es schon genug und mehr davon brauche ich nicht wirklich.
Da ist dann jedenfalls wieder der Teil, bei dem die eigentlichen Veränderungen an der Firmware vorgenommen werden, derjenige, der auf die Angebote eines "Frameworks" zurückgreifen kann/sollte - das erspart es, für jede mögliche Änderung an der Firmware auch diesen ganzen Aufwand jedesmal erneut umzusetzen.
Schon wenn man sich die Skripte aus "toolbox" ansieht, merkt man ja, daß die alles selbst enthalten, was für das Erstellen der Images erforderlich ist und das eben auch in jedem einzelnen Skript - der entscheidende Unterschied ist nur, was die jeweils in das neue Image einbauen.
Das kann man also auch zusammenfassen und dann muß man es (a) nicht immer neu machen und (b) bei Änderungen durch AVM nicht an mehreren Stellen Anpassungen vornehmen - das sind ja die Vorteile einer "Modularisierung".
========================================================================
Der Monolith, als der "modfs" heute daherkommt, war vielleicht notwendig, damit es überhaupt Leute gab, die sich damit befaßt und es benutzt haben ... den Ausgangspunkt des Ganzen, der aus einzelnen Skripten bestand, die man selbst nacheinander aufrufen mußte, haben viele ja gar nicht mehr auf dem Schirm.
Der war also eigentlich schon modularisiert und es war (im Nachhinein betrachtet) wohl auch ein Fehler, diese Aufsplittung in einzelne Skript-Dateien mit spezialisierten Aufgaben nicht in "modfs" zu übernehmen ... das machte dann natürlich (im ersten Schritt zumindest) die Handhabung auch für Benutzer leichter, wenn es nur ein Skript gab, was alles Wesentliche (mit Ausnahme der eigentlichen Modifikationen) enthielt und da keine weiteren Abhängigkeiten bestanden.
Die ganzen Dateien rundherum (bis hin zur passenden, statisch gelinkten BusyBox) kamen ja erst nach und nach wieder hinzu, als die unterstützten/getesteten Modelle zahlreicher wurden (und damit auch die BusyBox-Versionen von AVM, wo dann mal ein Kommando vorhanden war und es auf der nächsten Box (dem nächsten Modell) dann wieder fehlte) und man sich nicht mehr auf einen vorhandenen Umfang an Kommandos verlassen konnte.
Es wird jedenfalls kein "modfs" (von mir) geben für Modelle, die einen anderen Aufbau als die VR9-Boxen haben. Wenn das einer bauen will - bitte, es steht alles unter der GPLv2 bzw. GPLv3, was es dazu bräuchte. Die Teile, die ich noch nicht unter diese Lizenz gestellt habe (damit ich das erst mal in Ruhe selbst zu einem vorläufigen Ende bringen kann), braucht es für ein "modfs" für diese Boxen auch nicht.
========================================================================
Ich sehe jedenfalls nicht, wie das sinnvoll (ohne die Möglichkeit des Hinzufügens von SIAB, die ja bei anderen Modellen nicht so deutlich und einfach existiert) realisiert werden kann, daß eine FRITZ!Box (ohne weitere Modifikationen) dann "modfs" ausführt ... das braucht in jedem Falle zuvor schon ein passendes Image, was seinerseits einen Shell-Zugriff ermöglicht und wenn man das zusammenbaut und installiert, kann man auch gleich das "komplette System" dabei ändern.
Ich habe zwischendrin auch mal mit einem "Bootstrap-System" experimentiert, so wie es ja OpenWRT z.B. auch macht ... da wird ein (kleines) System auf die Box geladen und gestartet, mit dem man sich dann per SSH verbinden kann. In dieser Shell installiert man dann erst das eigentliche System (üblicherweise mit "sysupgrade"), wobei das bei OpenWRT dann eben auch jeweils fertige Images sind und die auch erst mal irgendjemand zusammengestellt haben muß (i.d.R. auf einem passenden Build-Host), damit man sie installieren kann.
Das ist bei einer FRITZ!Box auch nicht ganz so simpel ... denn auch wenn das vielleicht nicht direkt ins Auge sticht, so braucht das Extrahieren eines SquashFS-Images (aus der originalen Firmware von AVM) eben entsprechenden Speicherplatz und damit müßte man in so einem "Bootstrap-System", was dann seinerseits "modfs" ausführen soll (auch für andere Modelle als VR9), wenigstens bis zu einem funktionierenden USB-Stack kommen, damit man überhaupt irgendein Storage-Device für die Speicherung benutzen kann. Und das Einpacken eines SquashFS-Images braucht sogar "richtig viel" Hauptspeicher und da ist es schon hinderlich, wenn auch nur ein kleiner Teil davon durch das OS blockiert wird, das man aus dem Speicher gestartet hat.
Entweder man stoppelt sich den eigenen Kernel zurecht (und integriert da dann gleich alles, was es für USB bräuchte) oder man verwendet den AVM-Kernel und dann muß man wieder aufpassen, was man in das eigene System (wenn man das zum Download und zur Benutzung durch andere bereitstellen wollte) alles übernimmt - die AVM-eigenen Komponenten (Programme, Bibliotheken, etc.) sind an dieser Stelle dann tabu und so kriegt man (mit einem AVM-Kernel) nicht mal die LEDs der Box sauber zum Leuchten bzw. zum Anzeigen irgendwelcher "Zustände".
Damit ist die Idee mit dem "Bootstrap-System" auch schon wieder gestorben ...
========================================================================
Bei den anderen Modellen wird auch ein Format verwendet, wo die "filesystem.image" jeweils direkt ein SquashFS-Image ist und zwar auch gleich das mit dem "echten" Root-Filesystem. Da ist also das "Auspacken" deutlich einfacher als bei den VR9-Boxen (wo das Root-FS erst wieder im "Container" steckt, egal ob der nun SquashFS-Format oder "ext2" mit Dummy-Header benutzt) und auch das Erstellen des passenden (SquashFS-)Images braucht nur ein einzelnes Kommando - das sind schon erhebliche Unterschiede zum Aufbau der VR9-Modelle, wo das wieder schwerer "zu durchschauen" ist. Selbst die 7390- und 7270vX-Boxen waren da einfacher im Aufbau des Firmware-Images - auch wenn da der Kernel noch davor steht.
Das Einzige, was da also ggf. noch "sinnvoll" wäre aus meiner Warte, ist ein "Shell-Wrapper", der die Umgebung für den Aufruf der "modscript"-Dateien bereitstellt. Der muß dann auch nicht mehr unbedingt "interaktiv" sein (nicht umsonst war eine der ersten Erweiterungen von "modfs" die Möglichkeit, mit der "custom_modscripts"-Datei die Auswahl schon zuvor festzulegen und damit von den "Fragen" verschont zu bleiben) und dann bleibt da eigentlich kaum noch etwas an "Aufgaben" übrig, was so ein Skript als "Umgebung" für die "modscript"-Dateien leisten müßte. Sogar das "extract_version_values", mit dem man aus dem entpackten Verzeichnisbaum die Daten zur Firmware-Version u.ä. extrahieren kann, ist in beiden Repos (YourFritz + modfs) verfügbar.
Ich habe mich jetzt mal breitschlagen lassen und ein Beispiel für ein Skript eingecheckt (das findet sich auch im TGZ-File, das man von yourfritz.de laden kann - es heißt "run_modscripts"), was als ersten Parameter den Verzeichnisnamen der entpackten AVM-Firmware erwartet und dann ALLE "modscript"-Files, die es in "modscripts/*" findet, in alphabetischer Folge der Dateinamen auf die entpackte Struktur losläßt und zwar ohne Berücksichtigung irgendwelcher "precheck"- oder "postcheck"-Aktionen und auch ohne Ansicht der Person (aka "x-flags") oder einer event. vorhandenen "custom_modscripts"-Datei.
Das Skript erwartet, daß es sich in der üblichen Verzeichnisstruktur befindet, die beim Auspacken der TGZ-Datei von yourfritz.de oder beim Klonen des GitHub-Repos entstehen würde - und zusätzlich muß noch eine aktuelle "BusyBox"-Implementierung verfügbar sein (weil die BB-Kommandos teilweise andere Syntax verwenden, als die "großen Versionen") und über den Suchpfad gefunden werden. Für diese BusyBox wird dann ein Symlink unter "bin/000/busybox" angelegt und danach wird diese für die Applets in den "modscript"-Files verwendet.
Um das Entpacken und anschließende Packen muß man sich immer noch selbst kümmern ... wie gesagt: Das ist jeweils ein einzelnes Kommando (unsquashfs + mksquashfs) und auch das Zusammenkopieren von Kernel und Dateisystem, um eine Datei zu erhalten, die man in den Speicher der FRITZ!Box schreiben und starten lassen kann, ist nur ein zusätzliches Kommando (ggf. muß die TI-Prüfsumme vom Kernel entfernt werden).
Ich sehe nichts, was ansonsten für die oder auf den GRX-Boxen (gilt auch für IPQ und Puma, wobei für die IPQ-SoCs noch nicht mal die (ARM-)Binaries in "yf_bin" vorhanden wären) noch irgendeinen Sinn ergeben würde ... zumindest keinen, der eine weitergehende Automatisierung rechtfertigen würde. Die paar Kommandos notfalls auch noch zusammen in eine eigene Shell-Datei zu schreiben, halte ich für absolut zumutbar ... die Benutzung einer "debug.cfg" oder einer "rc.user" würde genau dieselben Fähigkeiten erfordern.
========================================================================
Und damit bin ich auch noch einmal bei
mod_rc_tail_sh (bei anderen Änderungen habe ich bisher keine Fehler gefunden) ... nachdem sich dann herausstellte, daß "multid" (der als Voraussetzung für "delay" gestartet sein muß) erst wesentlich später im Initialisierungprozess mit dem "supervisor" an der Reihe wäre (und es somit auch keinen Sinn macht, in der "/etc/boot.d/core/tail" auf den Start des "multid" zu warten), habe ich das für 07.19 und darüber dann doch anders gelöst.
Jetzt werden die Kommandos zum Auslesen der "rc.user" und zum Start der Kommandos in dieser Datei in einem zusätzlichen Skript "/etc/boot.d/core/rcuser" abgelegt und dieses dann durch einen zusätzlichen Service für den "supervisor" gestartet, der erst nach dem Start von "net.service" (was den Start des "multid" ebenfalls beinhaltet) an der Reihe ist. Dort wird dann weiterhin der Inhalt der "debug.cfg"/"rc.user" über "delay" gestartet, somit ist das per se unabhängig von der Ausführung der "/etc/boot.d/core/rcuser" und wird bei deren Ende auch dann nicht abgeräumt, wenn man sich beim Starten von "detached processes" nicht so genau auskennt (wo dann gerne der gerade gestartete Prozess beim Ende des Elternprozesses ebenfalls wieder abgeräumt wird).
Außerdem habe ich gleich noch den Teil "entschärft", der ansonsten (bei Ausführung auf einer FRITZ!Box) bei bisher leerer "debug.cfg"/"rc.user" ein "eventadd"-Kommando eingefügt hatte, damit die "Bei mir wird da nichts gestartet ..."-Meldungen nicht länger irritieren. Jetzt kann man "mod_rc_tail_sh" auch außerhalb einer FRITZ!Box problemlos auf eine entpackte Verzeichnisstruktur loslassen.
========================================================================
Alles wieder eingecheckt und in die
http://yourfritz.de/modfs-0.6.0-beta.tgz gepackt ... eine "Verlängerung" der Beta-Planung über den 01.05.2020 hinaus, halte ich aufgrund der jüngsten Änderungen nicht für erforderlich, solange niemand "schwere Fehler" findet. Und um auch das gleich noch festzuhalten ... "run_modscripts" ist nur ein Beispiel (wenn auch ein ziemlich ausführliches), wie man die Modifikationen auch auf anderen Systemen bzw. außerhalb einer FRITZ!Box benutzen kann ... das ist "ohne Support" bzw. ohne jeden Ehrgeiz, da irgendetwas "besser" machen zu wollen. Auch wenn ich das jetzt mal als Beispiel dazugepackt habe, will ich daraus kein zweites "modfs" machen.
