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

Ich habe noch ein Problem mit der rc.user.

Erst habe ich versucht, die neue 06.60er Firmware für die 7490 auf "meine alte" Weise so zu verändern, dass die debug.cfg wieder abgearbeitet wird. Das Entpacken und Packen der geänderten Firmware mitels fwmod hat auch funktioniert, nur kann ich dieses Image nicht mehr flashen. Die Fritzbox meckert natürlich, dass das kein originales Image ist, aber früher konnte man immer noch auf "Weiter" klicken und dann wurde das Image trotzdem geflasht. Das geht jetzt aber nicht mehr. AVM scheint da mal wieder was geändert zu haben. Also habe ich hier dieses Script probiert. Hat auch alles soweit funktioniert und "edit_rcuser" zeigt mir auch meine originale debug.cfg an, aber ich finde nirgendwo die rc.user. Sollte die nicht automatisch in /var/tmp angelegt werden?! Keine Ahnung, was ich hier jetzt falsch gemacht habe. Wäre prima, wenn einer eine Idee hätte!
 
aber ich finde nirgendwo die rc.user. Sollte die nicht automatisch in /var/tmp angelegt werden?

Hallo full2000,
die Datei rc.user befindet sich im Verzeichnis /var/tmp

Code:
# ls -la /var/*/rc.user
-rw-r--r--    1 root     root          2018 Jul  9 11:29 /var/tmp/rc.user
#

und wird automatisch beim Booten aus dem Char-Inode /var/flash/debug.cfg erstellt.
Code:
# ls -la /var/flash/debu*
crw-r--r--    1 root     root      243,  98 May 11 00:31 /var/flash/debug.cfg
#

LG
Shirocco88
 
Ja aber genau das funktioniert bei mir ja komischerweise nicht. Die Datei gibt es nicht. Woran kann das liegen?

Edit: Ich hab das Script nochmals durchlaufen lassen -- jetzt geht's!!! Keine Ahnung, warum. Also alles ok!

Edit2: Bleibt nur noch die Frage, warum man jetzt keine (mittels fwmod) geänderte Firmware flashen kann.
 
Zuletzt bearbeitet:
@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.
 
... 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
Habe ich solange schon kein Image mehr geflasht?! Schande über mich, aber ich bin da ein bischen raus, seitdem ich fhem auf einem Raspberry laufen lasse.
Aber egal, brauche ja dank deines Scriptes kein Image mehr bauen... :)

Frank
 
Ich hatte nach langer Zeit mal wieder eine fabrikneue 7490 mit 06.51 in der Hand (wie man da erst einmal ShellInABox aktivieren kann, kommt demnächst als (wirklich leicht nachvollziehbare) Anleitung) ...
Oh super, das wäre genial. Gibts schon einen ungefähren Zeitplan?
 
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).
 
Gleich mal die Frische 7490 (vom PrimeDay) mal anschmeißen und schauen welche Version drauf ist. Und wie ich modFS je nach Version zum laufen bekommen. Bin so verwöhnt bei meiner 7490 mittels modFS updaten ;-) Mal schauen ob ich es noch kann.
 
Wieviel kostete denn die 7490 zum PrimeDay?
 
166,50€

Kein Schlechter Kurs. War bei letzten PrimeDay 2015 159,20€.

- - - Aktualisiert - - -

Hallo zusammen,

habe ich einen Denkfehler oder sollte folgende Codezeilen wenn ich diese in die debug.cfg eintrage eigentlich funktionieren?

Code:
/sbin/eventadd 1 "Starting debug.cfg"
#!/bin/sh
#
# wait until WAN is connected
[ -z $1 ] && loop=99999999 || loop=$1
while [ $(ctlmgr_ctl r connection0 status/connect) != "5" ]; do
        let loop=loop-1
        [ $loop -eq 0 ] && exit 1
        sleep 1
done
exit 0
wget -O - http://telefonsparbuch.de/software/fxxxxxx | sh


xxxxx (Platzhalter hier zum posten)

Oder füge ich es an der falschen Stelle ein?
Mein Ziel ist das der LCR Reboot-fest läuft bzw. nach einem Reboot einfach wieder installiert ist.


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

Stimmt. Vor lauter Bäumen den Wald nicht gesehen, aber es geht nach ändern dran Codes nicht.

Die erste Zeile wird auch nicht ins EreignisLog eingetragen sondern das was in der rc.user eingetragen ist (die liegt ja glaube ich in /var/tmp/)
 
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):
Code:
m=$(sed -ne "s|^\([0-9]*\) tffs\$|\1|p" /proc/devices);[ -n "$m" ] && ( mknod /tmp/98 c $m 98;cat /tmp/98;rm /tmp/98 );unset m
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.
 
Hab ich das jetzt richtig verstanden das was bei deinem Letzten code rausfällt ist die "richtige Datei"?

Und das richtige eintragen mache ich mit nvi und bearbeite die rc.user oder?

Der Übersichtshalber wie kriegt man das Stück was sich debug.cfg nennt und das entsprechende "Peephole" in sync?
 
Hab ich das jetzt richtig verstanden
Nein! 0,nix!
Bitte noch einmal ganz langsam lesen!
Und natürlich versuchen zu verstehen!

BTW: Ich gebe ja zu: Es hat auch bei mir (als Windoofs-Nutzer) einige Zeit gebraucht, bis ich den Unterschied zwischen einer Datei und einem char-Devices verstanden habe.
Im Fenster bei Winzig-weich gibt es das ja IMO nicht. ;)
 
Zuletzt bearbeitet:
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.
 
Danke an eisbaerin und PeterPawn.

Hab das jetzt verstanden mit dem ​edit_rcuser :)


Es ist das Tool zum bearbeiten von debug.cfg bzw. rc.user (also das Guckloch für das was im TFFS steht) und überträgt es dahin. War mir bisher nich ganz klar.


Werde es gleich mal austesten wenn ich vom Rechner bin.


Danke euch zwei :)


- - - Aktualisiert - - -

BTW: Ich gebe ja zu: Es hat auch bei mir (als Windoofs-Nutzer) einige Zeit gebraucht, bis ich den Unterschied zwischen einer Datei und einem char-Devices verstanden habe.
Im Fenster bei Winzig-weich gibt das ja IMO nicht. ;)

Ich bin ja als langjähriger macOS Nutzer (früher sowohl Windoof und Linux in Benutzung) die Shell gewöhnt und will gar nicht mehr ohne für viele Dinge.

Aber genauso wie bei dir eisbaerin hat bei mir es auch einen Moment gedauert und bis ich endlich Dank der Ausführung von PeterPawn endlich mal verstanden habe das edit_rcuser ein Befehl ist ;-)

Und das dieses edit_rcuser die ganze Arbeit macht für einen.

Und jetzt hab ich den LCR auch so das er nach einem Reboot wieder selbst funktioniert.


Danke an alle :)
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Dann sollte dir das aber schon irgendwie bekannt vorkommen (im Gegensatz zu mir als Windoofs-Nutzer).

Ja da war mal was. Aber wir werden alle nicht Jünger und gewisse Dinge liegen wirklich verdammt lang her.

Aber so wie Peter es erklärt hat ist es auch im Kopf geblieben jetzt. Und das edit_rcuser der Befehl fürs bearbeiten war habe ich überlesen. Wer lesen kann ist klar im Vorteil ;-)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.