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

Hoffentlich nicht, die $ sollten "escaped" sein und später wird der Name über "eval" gebildet. Da die Version aus dem Superblock des Images erst ausgelesen wird, habe ich diese "verzögerte" Form gewählt, um trotzdem die Definitionen alle an einer Stelle versammeln zu können.
 
Diesen Patch braucht man nur dann, wenn man aus den Quelltexten des "squashfs4.3"-Paketes eine Version selbst übersetzen will, die ein mksquashfs erzeugt, das auch die AVM-Besonderheit versteht (eigentlich gibt es das verwendete Format "offiziell" nicht mehr ab SquashFS in Version 4). Da so ein Binary im Archiv vorhanden ist, erfordert die GPLv2, daß ich auch den (unfertigen) Patch parallel bereitstelle (grob, ich könnte es auch anders machen und den auf Anforderung auf einem geeigneten Datenträger zum Selbstkosten-Preis verschicken).
 
Ja genau verwende die Standard-Busybox 1.20.2 von AVM.

So ich denke das hilft dir weiter:
Code:
# cat spinner_command_errors.log
+ local src=/var/tmp/1437218854/filesystem_core.squashfs target=/var/media/ftp/1437218857 files= popd rc
+ [ -r /var/tmp/1437218854/filesystem_core.squashfs ]
+ [ -z ]
+ pwd
+ popd=/var/mod
+ cd /var/media/ftp/1437218857
+ sq_unsquashfs -info /var/tmp/1437218854/filesystem_core.squashfs
+ local rc=0 binary
+ eval echo $(bindir)/unsquashfs${sq_version}
+ bindir
+ get_hardware_revision
+ sed -n -e s/^HWRevision\t\(.*\)/\1/p /proc/sys/urlader/environment
+ echo /var/mod/bin/185
+ echo /var/mod/bin/185/unsquashfs
+ binary=/var/mod/bin/185/unsquashfs
+ /var/mod/bin/185/unsquashfs -info /var/tmp/1437218854/filesystem_core.squashfs
./modfs: line 2566: /var/mod/bin/185/unsquashfs: not found
+ rc=127
+ return 127
+ rc=127
+ cd /var/mod
+ return 127

Code:
Download eines aktuellen Firmware-Images vom FTP-Server des Herstellers ... OK
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Löschen des geladenen Firmware-Images ... OK
Entpacken des root-Dateisystem für die Modifikationen ...
sq_version=

Noch eine ergänzende Frage. Ich habe jetzt 6.24 und 6.30 drauf. Wenn ich jetzt aus der 6.24 das Skript erneut mit Update starte, wird dann die 6.30 komplett überschrieben oder stelle ich mir das zu einfach vor?
Falls ja wäre das dann ja wirklich super, dann hätte ich immer eine alte stabile Version und eine neuere zum Testen.
 
Zuletzt bearbeitet:
also brauche ich diesen Patch regulär nicht?



Was kann man machen wenn folgendes kommt:

Code:
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... Fehler

Das extrahierte 'äußere Dateisystem' kann nicht eingebunden werden.

Kann ich da was machen?

//EDIT: die FW ist 06.35
 
Zuletzt bearbeitet:
Ja, zumindest ist die Ursache jetzt klar die vermutete ... sq_version ist nicht gesetzt (deshalb ja das zusätzliche "echo"). Nachdem ich das aber im alten Protokoll in #179 gesehen hatte, daß dort irgendwo "sq_version" auf "3" gesetzt wurde (und ich auch nirgendwo ein "local ... sq_version" finden kann), verstehe ich es gerade nicht, daß dort sq_version nicht als "globale Variable" zur Verfügung steht.

Das ist immer ein Kreuz mit dem Unterschied zwischen "bash" und "ash" (ash kennt meines Wissens kein "declare" oder "typeset") - mal sehen, ob es hilft, wenn ich vorher "sq_version" im globalen Kontext schon verwendet habe ... das in den Zeilen 54/55 ist ja gerade keine Verwendung, die erfolgt erst später.

Verguckt habe ich mich wohl auch nicht, in #160 hat splenditnet das ja in Zeile 1307 auch gefunden ... da dort eigentlich keine "richtigen Subshells" zum Einsatz kommen sollten (das wären Code-Blöcke in runden Klammern), müßte das Setzen des Wertes in "get_squashfs_version" eigentlich "durchschlagen", aber offenbar reicht hier die Konstruktion mit "$(get_squashfs_version ...)" schon aus für einen gesonderten Variablen-Kontext (dann müßte das für "backticks" ja auch gelten), wo dann das Setzen von sq_version nur lokale Auswirkungen hat.

Da bei SQFS4 von AVM ein "Dummy-Superblock" mit "00:00" verwendet wird und der explizit vom Code als "sq_version=4" verstanden wird (und die Variable dann eine Ebene höher gesetzt wird), funktionierte das bei Version 4 dann trotzdem. Daß es bei mir auch mit einem Update von 06.24 auf 06.30 geklappt hat, liegt wohl doch nur daran, daß ich da auch noch "Überreste" ohne Versionsnummer im Dateinamen im "bin"-Unterverzeichnis hatte.

Jetzt da ich weiß, wo das Problem liegt, werde ich es lösen können ... danke für die zusätzlichen Informationen.
 
also brauche ich diesen Patch regulär nicht?



Was kann man machen wenn folgendes kommt:

Code:
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... Fehler

Das extrahierte 'äußere Dateisystem' kann nicht eingebunden werden.

Kann ich da was machen?

//EDIT: die FW ist 06.35

Ist das nicht genau das, was in #116 als Problem und in #142 als Lösungsvorschlag beschrieben wurde?
 
@BurningCrash:
Warten ... bisher funktioniert das Skript (steht weiter vorne in #117) nur für das Update von 06.2x auf 06.35, wenn SquashFS4 im Spiel ist. Ich hatte es schon einmal weiter, habe dann aber mit einem versehentlichen Checkout der falschen Version bei mir wieder alles "versaubeutelt", was das Arbeiten innerhalb der 06.35 angeht.

Wenn ich es fertig bringe, gibt es eine funktionierende Version für 06.35 noch heute, ansonsten sicherlich aber morgen.

Warum das so lange braucht (wenn man beide Kernel-Versionen unterstützen will), habe ich weiter vorne auch geschrieben - dann kommt eben noch hinzu, daß alleine das Packen mit SQFS4 auf der Box irgendwas zwischen 5 und 6 Minuten braucht ... das limitiert die mögliche Anzahl von Tests in einer definierten Zeit und wenn man sämtliche Zweige erneut durchtesten muß (zu "unit tests" habe ich auch etwas geschrieben), dann kostet das entsprechende Zeit, von den Vorbereitungen der jeweils passenden Umgebung ("von"-Version und Zielversion müssen ja passen und auch meine 7490 hat nur zwei verschiedene Sätze von Partitionen) ganz zu schweigen.

Das soll jetzt nicht heißen, daß ich mich von Dir gedrängelt fühle ... es soll nur erklären, warum so eine (simple) Änderung eben so lange braucht. Wenn ich mit einem kleineren Image (und damit weniger Zeitbedarf beim Packen) teste, kann ich das resultierende System ja hinterher schlecht starten ... da sind also die Testmöglichkeiten ohne "kompletten Ablauf" (vom Download vom FTP-Server bis zum Schreiben ins yaffs2) recht beschränkt.
 
Zuletzt bearbeitet:
Das ist sicherlich auch vom Zeitaufwand her nicht simpel. Glaube ich spreche für jeden wir sind froh das es das modfs von dir gibt! Und besser etwas länger warten und es läuft.
 
Kurze Rückmeldung: ./modfs update /var/media/ftp/USB/FRITZ.Box_7490.113.06.30.image von 6.24 lief zwar durch, allerdings endete ein Reboot in einem Bootfehler. Stecker gezogen und dann ging es. Sowohl 6.30 als auch 6.24 gehen. Danke für das Script.
 
Hallo,
ich habe heute zum ersten mal das skript auf einer FB 7362SL ausprobiert. Momentan läuft noch die 6.20 Version auf der Box, ich wollte gerne auf die 6.30 Version updaten, aber trotzdem noch telnet und zusätzlich die debug.cfg wieder haben. Leider war mein Versuch nicht erfolgreich.
Ich habe die 6.30 Firmware als firmware.image auf den USB-Stick gelegt und das skript gestartet. Das Entpacken funktioniert noch aber dann kommt die Fehlermeldung: "Prüfen der Firmware-Version des root-Dateisystems ... Fehler" und "Die Version der gefundenen Datei ... paßt nicht zum installierten System". Hab ich was falsch gemacht, oder läuft das skript noch nicht mit der 6.30 Firmware für die FB 7362SL?
 
@rogosch:
Das kann eigentlich nur heißen, daß Du das Skript nicht im "Update-Modus" aufgerufen hast (etwas weiter hinten als in #1 im Thread beschrieben, habe ich erst nachträglich eingebaut). Mit Update-Modus kann man ein anderes Firmware-Image benutzen, ansonsten muß das System in beiden Partitionen übereinstimmen. Wenn das auf dem Stick eine 06.30 ist und auf der Box eine 06.2x läuft, mußt Du es mit Update-Modus starten, Beispiel direkt über Deinem Beitrag in #170. Woher der Boot-Fehler in #170 kam, weiß ich aber auch nicht.
 
Zuletzt bearbeitet:
@PeterPawn: Vielen, vielen Dank für Deine Arbeit! Habe meine 7490 erfolgreich von 6.24 auf 6.30 upgedatet und bin sehr dankbar, dass Du das Skript geschrieben hast.
 
Ich versuche meine 7362SL von 6.20 auf 6.30 upzudaten. Nach dem Aufruf von
Code:
.# ./modfs update /var/media/ftp/HUAWEI-TFCARDStorage-00/FRITZ.Box_7362_SL.131.06.30.image
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 131.06.20

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/HUAWEI-TFCARDStorage-00/FRITZ.Box_7362_SL.131.06.30.image' wird als Quelle für die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
ext3-Dateisystem für loop-Mount wird entpackt OK
ext3-Dateisystem über loopback-Device einbinden ... OK
Entpacken des root-Dateisystem für die Modifikationen ... \
rebootet die Box. Das Update wird nicht durchgeführt. Irgendeine Idee? Alternativ: Gibt es ein Script, dass die Modifikationen am Image auf einem Linux System durchführt? Mir geht es um den Erhalt des Telnet Zugangs. OT: Kann man 'NoChecks=yes' wieder aktivieren?

Gruß schnurzelat
 
@schnurzelat:
Keine Idee, was den Fehler angeht ... eigentlich schon, aber nur Spekulationen.

Hilfreich wäre der Aufruf des Skripts mit "sh -x ...", dann sieht man nach einiger Zeit wenigstens, was da konkret abstürzt und zum Reboot führt. Auf einer 7362SL kann ich das selbst leider nicht testen ... aufgrund von kleinerer Hardware-Ausstattung würde ich zwei mögliche "Lösungen" (in Kombination anwenden) empfehlen:

1. Verwende einen USB-Stick mit einem ext2- oder ext3-Dateisystem, dann braucht es das Loopback-Image nicht.

2. Nimm nicht die neuere Version des Skripts (keine Ahnung, welche das hier ist, da fällt mir dann selbst auf, daß man das irgendwo in die Ausgabe schreiben sollte), sondern die ältere von http://yourfritz.de/modfs.tgz ... wenn es weiterhin zum Reboot kommt, bitte mal das Shell-Debug-Protokoll (in Code-Tags, wie in #174) dazulegen.

Ich würde ja auch eine optional zuschaltbare Shell-Debug-Protokollierung als "debug-Erweiterung" einbauen ... aber das Skript benutzt eben selbst auch die STDERR-Ausgabe für die Protokollierung des Ablaufs (das, was man auf der Console sieht, ist eigentlich stderr und nicht stdout) und da wird das etwas komplizierter.

Und "NoChecks" kann man nicht wieder einbauen ... wenn man einen passenden Editor nimmt, braucht das aber definitiv kein Mensch.
 
Danke für die Antwort. Ich habe das 'normale' script genommen. Nicht das für 6.35

Code:
+ return
+ loopback_used=1
+ unpack_directory=/var/tmp/2081_1437551193
+ [ 0 -eq 0 ]
+ progress 1 144
+ local msg mode=1
+ shift
+ get_localized de 144
+ localedir
+ echo /var/mod/locale
+ local lang=de lcfile=/var/mod/locale/de msgno=144 rc=0 msg
+ shift 2
+ sed -n -e /^144=/s/^[0-9]*=\(.*\)/\1/p /var/mod/locale/de
+ sed -e s/%{error}/${msgtext_error}/g
+ sed -e s/%{warning}/${msgtext_warning}/g
+ sed -e s/%{ok}/${msgtext_ok}/g
+ sed -e s/%{normal}/${msgtext_normal}/g
+ sed -e s/%{bold}/${msgtext_bold}/g
+ sed -e s/%{highlight}/${msgtext_highlight}/g
+ msg=Entpacken des root-Dateisystem für die Modifikationen ...
+ [ 58 -eq 0 ]
+ eval printf "Entpacken des root-Dateisystem für die Modifikationen ..." 
+ printf Entpacken des root-Dateisystem für die Modifikationen ...
+ return 0
+ msg=Entpacken des root-Dateisystem für die Modifikationen ...
+ [ 1 -eq 1 ]
+ echo -ne \r\x1B[KEntpacken des root-Dateisystem für die Modifikationen ...

Entpacken des root-Dateisystem für die Modifikationen ...+ return
+ spinner /var/tmp unpack_squashfs /var/tmp/1437551160/filesystem_core.squashfs /var/tmp/2081_1437551193
+ local dir=/var/tmp rc spin_from spinpid
+ shift
+ echo -ne   
  + date +%s
+ spin_from=/var/tmp/1437551193_2081
+ mkfifo /var/tmp/1437551193_2081
+ spinpid=2704
+ + unpack_squashfsrun_spinner
+  /var/tmp/1437551160/filesystem_core.squashfslocal /var/tmp/2081_1437551193 index=0
 positions=|/-\
+ read line
+ char=|
+ echo -ne \x1B[1D|
|+ let index+=1
+ [ 1 -eq 4 ]
+ read line
+ char=/

Ich habe mal den relevanten Teil heraus kopiert, denn das ganze log ist 134kb groß. Die letzten Zeilen wiederholen sich noch eine ganze weile, bis die box rebootet. Einen Stick mit extfs habe ich nocht nicht probiert.
 
@schnurzelat:
Wenn sich die Spinner-Ausgabe etwas hinzieht, dann arbeitet ja offenbar das "unsquashfs" noch eine Weile.

Etwas weiter oben habe ich einen Vorschlag für Änderungen des Skripts unterbreitet, mit denen man den Fortgang der vom Spinner "überwachten" Shell-Funktion in eine Datei protokollieren kann. Das wird bei Dir aber sicherlich nicht helfen, denn das ist ja nicht "restartfest", solange man das nicht irgendwie über das Netz (dafür braucht man dann entsprechende Vorbereitungen) auf einem anderen System protokolliert.

Ich würde erst mal abwarten wollen, ob das Verwenden eines "nativen Linux-Dateisystems" eine Änderung bringt. Irgendetwas muß bei Dir ja anders sein, denn bei anderen 7362SL soll es funktioniert haben (allerdings vor einem Update auf 06.30, aber das ist noch kein wirklicher Unterschied, erst zur 06.35 ist das von Bedeutung).

Was aus dem Problem von rogosch geworden ist, weiß man ja leider auch nicht ... das war wohl auch eine 7362SL, wobei da offenbar die Versionen nicht stimmten bzw. etwas falsch verstanden wurde.

Wenn die Box bei Dir kommentarlos neu startet, wäre im Nachgang zu so einem Neustart ja mal das Crash-Log interessant. Wenn das am Ende "memory pressure" als Ursache ausweist, hilft u.U. ein "prepare_fwupgrade start_tr069" vor dem Aufruf, damit werden dann viele AVM-Dienste heruntergefahren. Solange man alles Benötigte schon auf der Box hat (was bei Deinem Update-Aufruf ja der Fall ist), braucht es ja viele dieser Dienste nicht mehr. Bei einem Parameter != "start" sollte das USB-Subsystem (brauchst Du ja wegen des Sticks) unangetastet bleiben, nur das WLAN wird bei "start_tr069" in Mitleidenschaft gezogen. Wenn Du "start_from_internet" nimmt, bleibt der dsld aktiv und auch der ctlmgr ... das sind dann aber Platzfresser.
 
Mir ist was aufgefallen: Versucht das script, nach /var/tmp zu entpacken? Ich habe das script mal pausiert.

Code:
# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                48.0M     20.3M     27.7M  42% /wrapper
/dev/loop0               18.0M     18.0M         0 100% /
tmpfs                    55.6M     39.6M     16.1M  71% /var
tmpfs                    55.6M     68.0K     55.6M   0% /dev
/dev/mtdblock4            2.0M      1.1M    920.0K  55% /var/flash
/var/dev/nand            22.0M      1.5M     20.5M   7% /var/media/ftp
/dev/sda                945.9M    431.2M    514.8M  46% /var/media/ftp/HUAWEI-TFCARDStorage-00
/dev/loop1              124.0M      5.8M    111.8M   5% /var/tmp/2089_1437555798
# mount
rootfs on / type rootfs (rw)
/dev/root on /wrapper type yaffs (ro,relatime)
/dev/loop0 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock4 on /var/flash type yaffs2 (rw,sync,relatime)
/var/dev/nand on /var/media/ftp type yaffs2 (rw,sync,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
/dev/sda on /var/media/ftp/HUAWEI-TFCARDStorage-00 type vfat (rw,noatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=winnt,utf8,errors=remount-ro)
/dev/loop1 on /var/tmp/2089_1437555798 type ext3 (rw,relatime,errors=continue,user_xattr,acl,data=writeback)
 
Zuletzt bearbeitet:
@schnurzelat:
Eigentlich soll - solange kein natives Linux-FS (wegen der Rechte) mit genug freiem Speicher existiert - das ext3-Image auf dem USB-Stick angelegt, per loop-Device gemounted und dann beim Entpacken verwendet werden. Nach dem, was ich da sehe, würde ich das für korrekt halten. Vielleicht hängst Du ja noch ein "losetup -a" ran, damit man auch sieht, wo das Image liegt.

Wenn da ein Mount in /var/tmp erfolgt, sollte das nur der Mountpoint für das loop-Device sein, der wird halt (ist ja nur ein Directory) im tmpfs angelegt.
 
Konnte eine Box eines Freundes mit dem Skript (7490) auf 6.30 bringen. Hat bestens geklappt :)

Hast du schon gefunden wieso das aktuell nicht ganz klappt mit 6.35 wenn die drauf ist? Du hattest ja etwas in einem früheren Post erwähnt.
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
244,878
Beiträge
2,220,027
Mitglieder
371,604
Neuestes Mitglied
broekar
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.

IPPF im Überblick

Neueste Beiträge