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

[ttplayer]

Bei mir hat das Update von 6.24 auf 6.30 einwandfrei funktioniert. Allerdings habe ich die neue Firmware vom AVM Ftp heruntergeladen und auf meinen USB-Speicher geschoben.
Dann in Putty folgende Befehle benutzt:

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/7490/modfs.tgz | gunzip -c | tar x

./modfs update /var/media/ftp/Speichername/Imagename

 

[PeterPawn]

@scraemgo:
Das liegt vermutlich an einer "lazy sync" zwischen den AVM-Servern. Das Skript nutzt direkt den Server "download.avm.de" mit HTTP-Zugriff auf das FTP-Verzeichnis (weil der der einzige von den dreien ist, der das unterstützt, irgendwo im "Modifikationen"-Unterforum habe ich dazu vor 2 Monaten etwas geschrieben) und vermutlich war da die Datei noch nicht vorhanden. Wenn Du das jetzt noch einmal machst, würde mich das Ergebnis interessieren ... das sollte von der 06.24 auf die 06.30 eigentlich reibungslos klappen, am besten nimmst Du dazu die ältere Version von http://yourfritz.de/modfs.tgz ...
Alles Quatsch, offenbar fehlt auch da das "head"-Applet und damit wird die Version nicht aus der HTML-Seite geparsed ... dann hilft nur der vorhergehende Download. Da muß ich mir etwas anstelle des "head" einfallen lassen, sicherlich so etwas wie "sed".
Ich hatte mich halt von dem "nicht gefunden" im Text anstecken lassen und gar nicht auf das Protokoll im Code-Block darüber geschaut.

Wer das gleich bei sich selbst ändern will, ersetzt in der Zeile, die mit

| head -n 1)"

endet (es gibt nur eine einzelne davon), das Kommando einfach durch ein

| sed -n -e '1p')"

, das sollte auf dasselbe Ergebnis hinauslaufen. Ich ändere das bei Gelegenheit auch ab, aber nur dafür ist mir der Deployment-Aufwand zu hoch.

 

[scraemgo]

Habe es geändert und funktioniert soweit auch. Leider bekomme ich kurz darauf einen weiteren Fehler:

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

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom
FTP-Server des Herstellers.

Ermitteln der neuesten Version durch Suche auf dem FTP-Server ... OK
Es wurde eine neuere Version (113.06.30) auf dem FTP-Server gefunden.
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 ... Fehler
Die getroffene Auswahl ist ungültig.
#

Die Readme hilft mir leider auch nicht weiter.

 

[PeterPawn]

Leider bekomme ich kurz darauf einen weiteren Fehler:

An der Stelle käme jetzt die Auswahl eines Arbeitsverzeichnisses ... vermutlich steckt bei Dir kein USB-Stick dran oder der hat kein Linux-FS. Wenn da automatisch der NAND-Flash gewählt wurde und da nicht genug Platz frei ist, könnte das eine Ursache sein. Ich habe die (geschätzten) Werte zum Platzbedarf nicht angepaßt (glaube auch nicht, daß das notwendig ist). Kann es vielleicht sogar sein, daß Du gar keinen USB-Speicher angeschlossen hast (der NAND-Flash geht zwar auch, hat auch gleich ein Linux-FS, ist aber im Vergleich eher langsam und auch nicht unbedingt die beste Idee) und der freie Platz nicht so richtig ausreichend ist (ggf. auch irgendwelche Überreste im tmpfs von einem vorherigen Lauf vorhanden sind - das sollte zwar nicht passieren, aber mehr als eine Trap setzen kann ich auch nicht)?

 

[winstonS]

Hallo,
habe 6.30 eingespielt und bin erst dann auf die Suche nach debug.cfg gegangen...
Habe aber hier gelesen daß es mit einem Pseudoimage gehen sollte den telnetd wieder zu aktivieren.
http://www.antary.de/2015/07/17/avm-fritzbox-neue-firmwares-ohne-telnet/
Leider geht das Image von hier nicht
http://www.wehavemorefun.de/fritzbox/Starten_von_telnetd
Gibts irgendwo ein funktionierendes Pseudo Image?
P.S. ansonsten bleibt wohl nur Downgrade per Recovery Image...

 

[PeterPawn]

@winstonS:
Such mal hier ein bißchen, hatten wir auch gerade erst diskutiert ... mit "pseudo image telnet" solltest du eigentlich genug (aktuelles!) finden. Es muß auch nicht unbedingt eine 7490 sein, irgendwo im Zusammenhang mit einer 3490 hatte ich das auch noch einmal etwas ausführlicher erläutert.

 

[scraemgo]

An der Stelle käme jetzt die Auswahl eines Arbeitsverzeichnisses ... vermutlich steckt bei Dir kein USB-Stick dran oder der hat kein Linux-FS. Wenn da automatisch der NAND-Flash gewählt wurde und da nicht genug Platz frei ist, könnte das eine Ursache sein. Ich habe die (geschätzten) Werte zum Platzbedarf nicht angepaßt (glaube auch nicht, daß das notwendig ist). Kann es vielleicht sogar sein, daß Du gar keinen USB-Speicher angeschlossen hast (der NAND-Flash geht zwar auch, hat auch gleich ein Linux-FS, ist aber im Vergleich eher langsam und auch nicht unbedingt die beste Idee) und der freie Platz nicht so richtig ausreichend ist (ggf. auch irgendwelche Überreste im tmpfs von einem vorherigen Lauf vorhanden sind - das sollte zwar nicht passieren, aber mehr als eine Trap setzen kann ich auch nicht)?

In der Tat hatte ich keinen USB-Stick angeschlossen. Dachte der interne Flash reicht bei der 7490 aus. Habe dort ca. 370 MByte frei.

Mit einem USB-Stick bekomme ich aber dieselbe Fehlermeldung.

 

[PeterPawn]

IRC? Ich bin etwas ratlos ... die Stelle im Skript ist eigentlich nicht so kritisch. Die Nachricht hat die Nr. 144 und das ist der Code rundherum:

    # unpack squashfs root image
    progress 1 144
    spinner "$unpack_directory" [COLOR="#FF0000"]unpack_squashfs[/COLOR] "$baseimage" "$unpack_directory"
    rc=$?
    if [ $rc -eq 0 ]; then
        progress 3 96
        squashfs_blocksize=$(get_squashfs_blocksize $baseimage)
        squashfs_endianess=$(get_squashfs_endianess $baseimage)
        echo -e "$(get_localized $lang 145 "$unpack_directory/$squashfsdirname")" 1>&2
    else
        progress 3 97
        if [ $rc -eq 38 ]; then
            echo -e "$(get_localized $lang $rc "$baseimage")" 1>&2
        else
            echo -e "$(get_localized $lang $rc)" 1>&2
        fi
    fi

Da wird also nur noch das Dateisystem entpackt ... warum da bei Dir keine vorherige Abfrage des Arbeitsverzeichnisses kommt, sehe ich gerade nicht, allerdings ist mein NAND-FS auch ziemlich voll und kommt ohnehin nicht in Frage.

Vielleicht hilft es ja (wenn Du kein Shell-Debug machen willst), wenn Du im Kopf des Skripts die ganzen Speicherangaben so weit "hochdrehst" (400 MB?), daß er in jedem Falle auf den USB-Stick (der natürlich dann auch diesen Speicher frei haben muß) ausweichen muß. Da im Skript keine weitere Diagnose-Möglichkeit eingebaut ist, fehlt mir die Idee, wo es konkret hängt, es muß irgendwas ab Zeile 2469 oder so sein.

Wenn Du mit "sh -x ./modfs ..." startest, kommt zwar ein endlos langes Protokoll, aber wenigstens könnte man die Stelle mit dem Problem sehen ... notfalls die Fehlerausgabe (da läuft auch das Debug) mit "2>dateiname" irgendwohin umleiten und abspeichern. Wenn man dieses Protokoll dann hier hinterher wieder löscht, trägt das im IPPF auch nicht auf; an eine PM kann man keine Attachments hängen, der Text ist auf 5000 Zeichen begrenzt und eine E-Mail-Adresse will ich nicht immer herausgeben (obwohl sie vermutlich im Skript auch schon steht ).

 

[scraemgo]

IRC habe ich leider nicht.
Hier das Log, ich lösche es dann wieder.

.....

 

[PeterPawn]

Das Entpacken kommt bei Dir mit rc=127 zurück ... das heißt, daß er das Programm zum Entpacken nicht findet. Hast Du die "neue Version" für die Unterstützung der 06.35 genommen oder die etwas ältere von http://yourfritz.de/modfs.tgz ? Dem Inhalt des Logs nach die neuere ...

Eigentlich wird vom Skript die richtige Versionsnummer ausgewählt (in der Zeile "sq_version=3"), aber ich habe den Verdacht, daß da irgendwas mit den Dateinamen unter bin/185/ bei Dir nicht stimmt. Bitte mach mal ein Listing dort ... es sollte dort eine Datei "unsquashfs3" geben (und auch unsquashfs4, sowie mksquashfs3+mksquashfs4). Wenn die fehlen, ist irgendwas beim Einpacken bei mir schief gegangen (auf dem Server sieht das aber alles richtig aus) oder Du hast beim Auspacken etwas falsch gemacht. Bei der vorherigen Version hießen die Binaries noch einfach unsquashfs und mksquashfs - es gab ja noch keinen Grund zur Versionierung. Hast Du vielleicht nur das modfs-Skript selektiv aus dem Archiv gezogen und den Rest ignoriert? Ich bin ein wenig ratlos ... wenn es Dir auch so geht, mach mal bitte ein

find . -exec ls -ld '{}' \;

im modfs-Verzeichnis. Das zeigt alle dort liegenden Dateien in einer Liste an (dann hat sich das gesonderte Listing von weiter oben natürlich erledigt). Irgendwo muß ja der Grund für das "command not found" liegen.

 

[scraemgo]

Das möchte ich nicht ausschließen. Habe aber alles überprüft und das sah in Ordnung aus.

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/7490/modfs.tgz | gunzip -c | tar x

# find . -exec ls -ld '{}' \;
drwxr-xr-x    6 root     root           280 Jul 17 21:19 .
-rw-r-----    1 root     root           200 Jul 15 18:43 ./sha1sums
-rw-r-----    1 root     root           296 Jul 15 18:43 ./sha256sums
-rw-r-----    1 root     root           552 Jul 15 18:43 ./sha512sums
-rw-r-----    1 root     root           168 Jul 15 18:43 ./md5sums
drwxr-xr-x    2 root     root           140 Jul 17 21:19 ./modscripts
-r-xr-xr--    1 root     root         11678 Jul 15 18:41 ./modscripts/gui_boot_manager
-r-xr-xr--    1 root     root          1201 Jun  8 15:17 ./modscripts/mod_enable_telnet
-r-xr-xr--    1 root     root          3818 Sep 22  2014 ./modscripts/edit_rcuser
-r-xr-xr-x    1 root     root          2251 Sep 22  2014 ./modscripts/mod_rc_tail_sh
-r-xr-xr--    1 root     root          1349 Sep 22  2014 ./modscripts/mod_profile
drwxr-xr-x    3 root     root           140 Jul 17 21:19 ./bin
drwxr-xr-x    2 root     root           120 Jul 17 21:19 ./bin/VR9
-r-xr-xr-x    1 root     root        105824 Sep  3  2014 ./bin/VR9/mksquashfs3
-rwxr-xr-x    1 root     root        126348 Jul  4 23:53 ./bin/VR9/unsquashfs4
-r-xr-xr-x    1 root     root         56420 Sep  3  2014 ./bin/VR9/unsquashfs3
-rwxr-xr-x    1 root     root        175804 Jul 15 00:29 ./bin/VR9/mksquashfs4
lrwxrwxrwx    1 root     root             3 Jul 17 21:19 ./bin/203 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 17 21:19 ./bin/175 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 17 21:19 ./bin/185 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 17 21:19 ./bin/212 -> VR9
drwxr-xr-x    2 root     root            60 Jul 17 21:19 ./files
-r--r--r--    1 root     root        144392 Sep 14  2014 ./files/128MB_ext3.gz
drwxr-xr-x    2 root     root            80 Jul 17 21:19 ./locale
-r--r--r--    1 root     root         10771 May 11 17:50 ./locale/en
-r--r--r--    1 root     root         12570 Jun  8 15:13 ./locale/de
-r--r--r--    1 root     root         18092 Sep  3  2014 ./COPYING
-r--r--r--    1 root     root         28257 May 11 18:04 ./README.ger
-r--r--r--    1 root     root         17964 May 11 18:09 ./README
-r-xr-----    1 root     root         70624 Jul 18 01:29 ./modfs

 

[splenditnet]

Hallo scraemgo,
ich habe mir deine Befehlssequenzen angesehen:

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/7490/modfs.tgz | gunzip -c | tar x

# find . -exec ls -ld '{}' \;
SNIP
-r-xr-----    1 root     root         70624 Jul 18 01:29 ./modfs

irgendwie ist das modfs skript gegenüber dem Download/Orginal von PeterPawn noch nachträglich verändert worden;

bei mir sieht es wie folgt aus:

# find . -exec ls -ld '{}' \;
SNIP
-r-xr-----    1 root     root         70619 Jul 15 18:42 ./modfs

der Rest ist bei mir gleich;

Frage: Was ist da noch geändert worden ? Hat dies evtl. mit dem Problem zu tun ?

Gruß
Splenditnet

 

[splenditnet]

Hallo PeterPawn,
habe gerade, dass für die FB3390 (HW Rev 193) noch kein Softlink im bin-Verzeichnis existiert:

# grep ^hwrevs_supported modfs
hwrevs_supported="175 185 193 203 212"
#

# ls -la bin
drwxr-xr-x    3 root     root           140 Jul 18 09:25 .
drwxr-xr-x    6 root     root           280 Jul 18 09:25 ..
lrwxrwxrwx    1 root     root             3 Jul 18 09:25 175 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 18 09:25 185 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 18 09:25 203 -> VR9
lrwxrwxrwx    1 root     root             3 Jul 18 09:25 212 -> VR9
drwxr-xr-x    2 root     root           120 Jul 18 09:25 VR9
#
# grep ^ftp_path_193 modfs
ftp_path_193="/fritz.box/fritzbox.wlan_3390/firmware/deutsch/FRITZ.Box_3390.\$version.image"
#

Gruß
Splenditnet

 

[scraemgo]

Frage: Was ist da noch geändert worden ? Hat dies evtl. mit dem Problem zu tun ?

Nein hat damit nichts zu tun. Ohne die Änderungen wäre ich gar nicht so weit gekommen ;-) Siehe ein paar Beiträge weiter oben.

 

[PeterPawn]

@splenditnet:
Danke für den Hinweis ... habe das Skript zum Zusammenpacken entsprechend modifiziert, damit ich da nicht immer die Verzeichnisse aufführen muß (das ist selektiv, da bei mir noch weitere Dateien im Verzeichnis liegen) und eine neue Version (des alten Skripts!) steht ab sofort auf dem Server. Auch die Änderung von "head" nach "sed" ist da bereits drin.

Die neuere Skript-Version hat noch mehr "diffs" zum derzeitigen Stand, da lohnt sich das nicht extra, die kommt (hoffentlich) im Laufe des Tages ohnehin auf den Server.

@scraemgo:
Dir würde ich die Verwendung von yourfritz.de/modfs.tgz (also ohne "7490") vorschlagen (neues Verzeichnis zum Auspacken verwenden) und dann eine Änderung der Zeile:

    "$@" >"$spin_from" 2>/dev/null

in "spinner" auf

    "$@" >"$spin_from" 2>/var/tmp/spinner_command_errors.log

Die Debug-Ausgabe der vom Spinner "überwachten" Funktion landet dann nicht mehr im Nirwana, sondern in dieser Datei und vielleicht findet sich da ja der Grund, warum das Kommando nicht gefunden wird. Wenn Du dann noch vor die Zeile 2741 (gilt für die Version, die Du noch nicht verwendest) ein "set -x" einfügst:

[COLOR="#FF0000"]    set -x[/COLOR]
    spinner "$tmpdirbase" unpack_squashfs "$baseimage" "$unpack_directory"

, dann wird auch nur der entscheidende Teil protokolliert.

PS: Das Log aus #149 könnte meinetwegen weg.

 

[scraemgo]

Ich glaube du hattest einen kleinen Zahlendreher drin. Die Zeile lautet 2471, nicht 2741.

Habe nun die "alte" Version verwendet und da hat auf Anhieb alles funktioniert. Danke soweit für deine Hilfe. Wo jetzt der Fehler lag werden wir wohl nicht mehr herausfinden können oder?

 

[PeterPawn]

Möglich, war ein- und nicht abgetippt bzw. kopiert.

Was da jetzt bei der "neuen Version" für SquashFS3 eventuell nicht funktioniert, muß ich erst noch einmal ausführlich schauen, das verzögert die neue Version weiter. Ich will bloß nicht auf Dauer unterschiedliche Versionen für 2.6 und 3.10 haben.

Wenn Du das noch einmal probieren willst mit der neueren Version (Du kannst ja später abbrechen anstatt das FS zu schreiben), suche ich auch den Fehler noch gezielter (anstatt nur bei mir den Durchlauf zu testen) ... aber bei mir tritt er eben auch mit der neueren Version (so wie sie noch auf dem Server steht) nicht auf - auch nicht für Firmware auf 2.6.32-Basis. Das Update von 06.24 auf 06.30 lief einwandfrei durch (die Probleme kommen dann erst, weil man ein paar Binaries zusätzlich ersetzen muß/sollte).

 

[scraemgo]

Verständlich, eine Version wäre auf jeden Fall wünschenswert.

Gerne helfe ich dir bei der Fehlersuche. Du musst mich dann nur nochmal anleiten, was ich genau versuchen soll.

 

[PeterPawn]

Wie oben, nur die Stellen verschieben sich dann eben in der Version vom Server ein wenig (aber Du hast den Zahlendreher ja auch überstanden, das findest Du schon) ... wenn Du noch eine zusätzliche "Kontrolle" einbauen willst, packst Du zwischen das "set -x" und den Aufruf zum Auspacken noch ein

echo "sq_version=$sq_version" 1>&2

, da darüber die Version des zu verwendenden Programms zum Entpacken gesteuert wird. Das Setzen auf "3" hatte ich im Protokoll in #179 ja gesehen ... ich will nur sicher sein, daß das nicht irgendwo wieder "verloren" gegangen ist, weil ein Kontextwechsel stattgefunden hat. Andererseits ist das bei sq_version=4 eigentlich genauso (und auch da funktioniert es bei mir) ... da schießen eben die Spekulationen ins Kraut. Was ich mir event. noch denken könnte, wäre ein Fehler in der Shell der Busybox ... aber ich gehe davon aus, daß Du die von AVM (1.20.2) verwendest und ansonsten etwas dazu geschrieben hättest. Es ist eben komisch ... wenn Du wirklich den Fehler weiter umzingeln könntest, wäre das eine echte Hilfe; ich konnte das Problem gestern bei mir nicht nachstellen und will jetzt nicht mehr auf den alten Branch zurück, um das zu suchen.

 

[splenditnet]

Hallo PeterPawn,
wenn ich mir das im Trockentest ansehe, denke ich dass da im modfs script möglicherweise die Umgebungsvariablen sq_pack/sq_unpack zu früh befüllt wurden,
sprich die sq_version Umgebungsvariable ist noch leer

line 54: + sq_pack=$(bindir)/mksquashfs${sq_version}
line 55: + sq_unpack=$(bindir)/unsquashfs${sq_version}
SNIP
line 1307: sq_version=3

# ls -la bin/VR9
drwxr-xr-x    2 root     root           120 Jul 18 09:25 .
drwxr-xr-x    3 root     root           140 Jul 18 09:25 ..
-r-xr-xr-x    1 root     root        105824 Sep  3  2014 mksquashfs3
-rwxr-xr-x    1 root     root        175804 Jul 15 00:29 mksquashfs4
-r-xr-xr-x    1 root     root         56420 Sep  3  2014 unsquashfs3
-rwxr-xr-x    1 root     root        126348 Jul  4 23:53 unsquashfs4
#

dies würde dann bedeuten, dass mksquashfs bzw. unsquashfs als Binany angezogen werden, die jedoch nicht vorhanden sind.

Vorschlag: die Reihenfolge der Variablen-Deklarationen anpassen und erneut testen.

Gruß
Splenditnet