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

@full2000:
Na ja, das ist für diejenigen, die sich intensiver damit befassen, nicht wirklich eine Frage ... seit Mitte Januar (das waren die "Vorwehen" der 06.51 für die 7490) läßt AVM kein Update mit einem nicht korrekt signierten Image mehr zu (und kein Downgrade über das GUI, aber das hat teilweise auch technische Gründe).

Wer weiterhin lieber mit fwmod arbeiten will, der muß halt seinen eigenen öffentlichen Schlüssel einmal in ein Image einbauen lassen, welches er dann auf irgendeinem anderen Weg (z.B. als "in-memory image" über den Bootloader) installieren läßt. Anschließend sollte auch ein per fwmod signiertes Image sich ganz normal über das AVM-GUI installieren lassen ... u.a. deshalb wurde ja der ganze Aufwand in Freetz (Signieren von Images) und YourFritz (Skripte zur Signaturbehandlung und für den Bootloader) betrieben.

Bis zum Wegfall des Routerzwangs habe ich das sicherlich auch geschafft ... die notwendige Software ist eigentlich fertig bzw. das Vorgehen ausreichend getestet.

Es ist am Ende praktisch wieder dasselbe Image, was auch modfs-Starter verwendet hat ... kombiniert mit einem Kernel und einen so weit zusammengestrichenen Dateisystem, daß man keine AVM-Komponenten braucht (mit Ausnahme des Kernels, aber der steht unter GPL und am Ende ist AVM auch selbst schuld, wenn man keinen eigenen funktionsfähigen Kernel erstellen kann, weil die Hälfte fehlt - diesen Standpunkt vertrete ich ja noch immer) und damit auch ein komplettes Image als Download bereitstellen kann, das nur noch wahlweise mit dem PowerShell-Skript (für Windows-User) oder mit dem Posix-Shell-Skript aus dem YourFritz-Repo geladen werden muß und dann das ShellInABox-Image wieder ins Wrapper-FS schreibt, womit beim nächsten Start dann SIAB geladen wird.

Im Prinzip ist das auch alles schon einmal veröffentlicht (den Zwischenstand eines (unvollständigen) Skripts zum Erstellen so eines Images habe ich gerade mal ins YourFritz-Repo eingecheckt, aber das wird nicht heute oder morgen fertig) und wird nur anders zusammengebaut ... und natürlich braucht es noch die Beschreibung. Als ich das in Angriff genommen hatte, kam dann etwas anderes dazwischen und diese Baustelle ist erst einmal wieder nach hinten gerutscht auf der ToDo-Liste. Wer es eilig hat, müßte selbst ein Image zusammenbauen ... das ist weniger aufwändig, als man vielleicht glaubt und (wenn man z.B. die BusyBox aus modfs nimmt) man braucht zwar ein Linux-System, aber keine Freetz-Buildumgebung (höchstens noch das richtige tar-Applet der Busybox, wenn man die Möglichkeit des Auspackens wie in meinem Skript verwenden will).

Wenn Du das "exit" vor dem "wget" machst, wirst Du wahrscheinlich kein LCR-Update laden können.

Die rc.user und die debug.cfg sollten identisch sein.

Warum?

So ein TFFS-Node ist nichts weiter als ein "Fenster" oder ein "spy hole" (Guckloch) in den TFFS-Treiber (der speichert seine Daten dann irgendwo, wo das genau erfolgt, spielt hier keine Rolle). Wenn da durch das Fenster mit der Nummer 98 gesehen wird, steht da irgendein Inhalt. Egal wie man das "Fenster" (die Gerätedatei) im Filesystem nennt, man sieht immer denselben Inhalt im TFFS ... halt unter verschiedenen Namen.

Da es sich beim TFFS-Treiber um einen Treiber für "zeichenorientierte Geräte" (char-Devices) handelt, unterstützt der bestimmte Dateioperationen nicht, in erster Linie ist es hier das Positionieren des Lese-/Schreibzeigers an eine festgelegte Stelle ... einer der entscheidenden Gründe dafür dürfte es sein, daß die Daten im Hintergrund komprimiert gespeichert werden und man daher zur Ermittlung so einer Position die Datei in einen Zwischenpuffer entpacken müßte. Also verzichtet man einfach auf solche Positionier-Operationen (lseek()), denn bei vielen char-Devices machen die ohnehin keinen Sinn. Es ist wenig zielführend, z.B. bei einer Tastatur (das klassische Beispiel für ein "char device") sich an das Ende der "Datei" zu positionieren.

Im Ergebnis kann man eben solche Dateien nicht fortschreiben (dazu müßte man sich ja an das Ende des bisherigen Inhalts positionieren) und da viele normale Programme auch gerne mal auf so ein lseek() zurückgreifen (das geht vom FTP-Server bis zum Editor "vi"), ist es am einfachsten, den aktuellen Inhalt so eines TFFS-Nodes in eine reguläre Datei zu schreiben (dort geht dann auch lseek() und vieles andere) und dort zu be- oder verarbeiten.

Das macht man am besten mit dem Kommando "cat", wobei auch jedes andere Kommando, welches sich auf unterstützte Operationen beschränkt, benutzt werden kann ... es gibt z.B. keinen Grund, für die Suche innerhalb einer "TFFS-Datei" mit "grep" oder "sed" erst eine solche Kopie anzulegen. Für das Zurückschreiben von Inhalten in einen TFFS-Node ("in einem Rutsch", denn Positionieren geht eben nicht) verwendet man am einfachsten ebenfalls "cat".

Damit gibt es eben nicht wirklich zwei verschiedene "Dateien" rc.user und debug.cfg ... macht man es richtig (wie gesagt, beide Namen sind Schall und Rauch und man könnte die Datei auch "Max_und_Moritz" nennen), dann beziehen sich beide Gerätedateien auf dasselbe "peephole" ins TFFS.

Die Änderung durch "modfs" beim Start macht jetzt nichts anderes, als am Ende des Init-Prozesses den Inhalt dieses TFFS-Nodes in die Datei /var/tmp/rc.user zu übertragen und von dort auszuführen. Theoretisch könnte man danach diese Datei auch gleich wieder löschen, denn eine Änderung an dieser kann keine Auswirkungen auf den Inhalt des TFFS haben ... diese Datei ist nur eine Kopie des Inhalts beim Start des Systems.

Für die Änderung am Inhalt des TFFS habe ich extra das Skript "edit_rcuser" zum modfs hinzugefügt. Dieses macht nichts anderes, als den aktuellen Inhalt des TFFS in eine temporäre Datei zu schreiben und einen Editor für diese "Kopie" des Inhalts aufzurufen. Wird dann der Editor beendet, wird der neue und der alte Inhalt verglichen und sollte etwas geändert worden sein, kann man sich entscheiden, den neuen Inhalt dieser Kopie in das TFFS zu schreiben. Auch hier besteht praktisch kein Zusammenhang mehr zur "/var/tmp/rc.user", diese ist nicht der Gegenstand der Änderung mit "edit_rcuser" und damit vorgenommene Änderungen werden auch nicht in dieser Datei sichtbar (erst nach dem nächsten Start, wenn sie wieder eine Kopie des dann aktuellen Inhalts ist).

Ändert man jetzt den Inhalt des TFFS-Node 98 auf irgendeinem anderen Weg, muß man sich nur an dieses Vorgehen halten.

Insofern kann man auch immer schlecht sagen, ob jemand bei der Nennung von "debug.cfg" nun das richtige Vorgehen beim Editieren verwendet oder nicht. Wenn es sich bei dieser "debug.cfg" um eine mit "mknod" eingerichtete Gerätedatei für den Node 98 im TFFS-Treiber handelt, dann ist das eben ein anders benanntes "Fenster" ins TFFS und man kann (unter Beachtung der oben gemachten Bemerkungen) auch den Inhalt über diesen "Namen" ändern. Ist das eine vollkommen andere (reguläre) Datei, ist das eben auch eine vollkommen andere Stelle im Dateisystem.

Normalerweise würde so eine geänderte reguläre Datei "/var/flash/debug.cfg" auch einfach beim nächsten Start wieder verschwunden sein und damit merkt man schon daran, daß man bei der Änderung etwas falsch gemacht hat ... aber hier kommt jetzt eine weitere "Besonderheit" einiger NAND-Boxen zum Tragen. Diese mounten nämlich unter dem Pfad "/var/flash" eine kleine (1-2 MB) yaffs2-Partition, in der dann die "char devices" für den TFFS-Inhalt angelegt werden. Da dieses Dateisystem auch über einen Neustart hinaus seinen Inhalt behält, wird auch eine dort als "regular file" gespeicherte "debug.cfg" einen Neustart überleben. Da das aber ein anderer Speicherplatz ist (eben das yaffs2 und nicht das TFFS), "sieht" das System durch das Fenster 98 ins TFFS eben nicht das, was in der regulären Datei "debug.cfg" unter /var/flash steht.

Wenn hier also in einer "debug.cfg" etwas steht, was beim Systemstart nicht ausgeführt wird, liegt die Vermutung nahe, daß es eben der falsche Speicherort ist. Der tatsächliche Inhalt des TFFS-Nodes wird folgendermaßen angezeigt (als Einzeiler für C&P):
Zuerst wird die "major ID" des TFFS-Treibers ermittelt (die ist dynamisch und zwar relativ stabil für ein Modell (und einen Kernel), aber das muß nicht immer so bleiben - das hängt damit zusammen, wie der TFFS-Treiber im Kernel initialisiert wird) und wenn diese gefunden wird, dann wird ein "char device" mit der "minor ID" 98 angelegt im /tmp-Verzeichnis, dessen Inhalt angezeigt und im Anschluß wird diese "Datei" dann auch gleich wieder gelöscht. Wäre das jetzt eine reguläre Datei, wäre zusammen mit dem Datei-Inode natürlich auch der Inhalt verschwunden (in Grenzen, aber das ist ein anderes Thema) ... hier wird lediglich das Fenster wieder geschlossen und der Inhalt dahinter bleibt erhalten.

Nein, das hast Du vermutlich - zumindest teilweise - falsch verstanden. Der Einzeiler zeigt den tatsächlichen Inhalt von Node 98 an, ohne sich auf irgendwelche Dateinamen zu stützen.

Wenn man diesen Inhalt editieren will, gibt es genau dafür das Skript "edit_rcuser", welches man sich installieren lassen sollte von "modfs", wenn man nicht so ganz genau weiß, wie das mit dem Editieren im TFFS funktioniert.

Das "nvi"-Skript von AVM funktioniert zwar auch (immer unter der Voraussetzung, daß /var/flash/debug.cfg auch tatsächlich ein TFFS-Node ist und keine reguläre Datei), aber da dieses Skript die temporäre Datei auch dann zurückkopiert, wenn sie sich gar nicht geändert hat, ist das Gülle ... außer einer zusätzlichen Schreiboperation - unabhängig von Änderungen - erreicht man damit aber dasselbe wie mit "edit_rcuser", nur muß man sich eben darauf verlassen, daß /var/flash/debug.cfg existiert und tatsächlich der TFFS-Node ist.

Um diese Unterschiede kümmert sich "edit_rcuser" allerdings selbst ... auch wenn man versehentlich eine falsche Datei unter /var/flash/debug.cfg liegen haben sollte, stört sich "edit_rcuser" nicht daran und bearbeitet auch dann den eigentlichen Inhalt des TFFS.