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

[PeterPawn]

Hat einer von Euch event. ein anderes "tar"-Kommando (z.B. aus den gnu-utils) auf der Box?

Das "short read" liegt vermutlich daran, daß es in der Datei keinen "end header" (ein leerer File-Header) gibt ... aber da das Kommando trotzdem mit rc=0 beendet wird, gibt es eigentlich keinen Grund für den Fehler 62:

extract_kernel()
{
        local src="$1" target="$2" tmp rc mp tmpdir
        debug "extract_kernel: src=$src, target=$target"
        tar -xOf "$src" "$firmware_kernel_image" >"$target" 2>/dev/null
        rc=$?
        if [ $rc -ne 0 ]; then
                rc=62
        fi
        debug "extract_kernel: exiting, rc=$rc"
        return $rc
}

62 ist also die direkte Folge eines Endes des "tar"-Aufrufs mit einem Fehlercode. Das "tar"-Applet der Busybox geht über ein "short read" aber ohne einen Fehlercode zu setzen. Es muß also irgendein Problem beim Aufruf des "tar"-Kommandos sein ... wenn das auf "stderr" protokolliert wird, sollte ein testweises Umleiten dieses Handles (oben wird er ja nach /dev/null gemappt) in eine Datei zur Protokollierung eigentlich Auskunft geben können. Aber warum/was sollte da schief gehen, außer daß der Dateiname nicht stimmt (das ist aber ./var/tmp/kernel.image, zumindest bei mir), das Archiv nicht existiert (das wird vorher geprüft) oder beim Schreiben der Ausgabedatei ein Fehler auftritt (das kann eigentlich nur noch "no space left on device" sein, denn das Skript läuft ja als "root" und es dürfte keine Probleme mit den Dateirechten geben)?

Mir fehlt etwas die Phantasie und nachstellen kann ich das bei mir auch nicht. Allerdings habe ich eben sowohl eine Swap-Partition auf einer HDD in Benutzung als auch ein "native filesystem" (ext3) im Einsatz.

 

[PeterPawn]

So, gerade mit dem tar-Applet der Busybox 1.23.2 (das ist die, die ich meinerseits auf der 7490 verwende) noch einmal getestet:

root@FB7490:~ $ tar -xOf FRITZ.Box_7490_LabBETA.113.06.36-31504.image ./var/tmp/kernel.image >/dev/null;echo $?
tar: short read
0
root@FB7490:~ $ which tar
/bin/tar
root@FB7490:~ $ l /bin/tar
lrwxrwxrwx    1 root     root             7 Tue Aug 18 11:26:11 2015 /bin/tar -> busybox
root@FB7490:~ $

Bei mir gibt es also nach dem "short read" keinen Returncode ungleich 0. Warum das bei Euch anders ist (womöglich liegt es an der älteren Version der Busybox, wenn Ihr das Original von AVM verwendet), weiß ich nicht. Zum "short read" generell hatte ich hier mal getestet ... wenn sich das jetzt anders darstellt, würde ich eher dazu tendieren, das "image"-File vor der Verwendung von modfs in eine Form zu bringen, an der sich das tar-Applet nicht stört oder eine aktuellere Busybox zu verwenden, anstatt am Skript zu ändern.

 

[maulich]

Bei mir wird folgendes tar verwendet:

FritzBox7490:/var/media/ftp/BUFFALO-HD-PCTU3-01/bin/modfs$ tar

BusyBox v1.22.1 (2015-06-09 10:54:06 CEST) multi-call binary.
...

das stammt aus der firmware...
Ansonsten verwende auch ich eine Swap-Partition und ein natives Dateisystem auf der HDD (ext4).

woher stammt deine tar Version???

wirklich seltsam...

 

[maulich]

Ok, erst jetzt gesehen, daß Du nicht die AVM Busybox benutzt...das ist dann offensichtlich des Rätsels Lösung...

Ob jetzt das Skript verändert wird, oder eine aktuellere Version der Busybox besorgt wird ist m.E. Geschmackssache...

 

[PeterPawn]

Als "quick fix" kann man ja einfach das "extract_kernel" so abändern:

extract_kernel()
{
        local src="$1" target="$2" tmp rc mp tmpdir
        debug "extract_kernel: src=$src, target=$target"
        tar -xOf "$src" "$firmware_kernel_image" >"$target" 2>/dev/null
[COLOR="#FF0000"]        rc=0[/COLOR]
        if [ $rc -ne 0 ]; then
                rc=62
        fi
        debug "extract_kernel: exiting, rc=$rc"
        return $rc
}

Dann wird eben ein Fehler des tar-Kommandos nicht mehr bemerkt ... solange das Extrahieren des Kernels trotzdem funktioniert, sollte das kein Problem sein. Wahrscheinlich trifft es die Stelle mit dem Auspacken von "filesystem.image" dann aber noch einmal genauso ... insofern ist das "Umpacken" vielleicht auch keine so schlechte Idee.

cd /;rm -r /var/repack;mkdir /var/repack;cd /var/repack;tar -x -f [COLOR="#008000"]/var/media/ftp/FRITZ.Box_7490_LabBETA.113.06.36-31504.image[/COLOR];echo untar=$?;tar -c -f [COLOR="#0000FF"]/var/media/ftp/test.image[/COLOR] .;cd /;rm -r /var/repack

Den grünen und blauen Teil entsprechend den Gegebenheiten anpassen (und an die eigenen Vorlieben) und das neu erzeugte File anstelle des AVM-Images verwenden. Zumindest bei mir gibt das kein "short read" mehr für das tar-File.
EDIT: Das oben bezieht sich natürlich auf die Ausführung auf der FRITZ!Box ... ansonsten sollte man anstelle von /var/repack etwas anderes nehmen, wenn man so ein Verzeichnis selbst verwendet für irgendwelche anderen Sachen.

 

[splenditnet]

Hallo zusammen,
ich verwende FW 6.36-31214 mit Stock-Tar-Binary

# tar --help
BusyBox v1.22.1 (2015-06-09 10:54:06 CEST) multi-call binary.

Usage: tar -[cxtJhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

Operation:
        c       Create
        x       Extract
        t       List
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        J       (De)compress using xz
        O       Extract to stdout
        h       Follow symlinks
        exclude File to exclude
        X       File with names to exclude
        T       File with names to include
#
# /bin/busybox
BusyBox v1.22.1 (2015-06-09 10:54:06 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, arp, arping, ash, basename, brctl, bunzip2, bzcat, bzip2, cat, chgrp, chmod, chown, chroot, cmp, cp, cut, date, dd, df, dirname, dmesg, dnsdomainname, du, echo, egrep, env,
        ether-wake, expr, false, fgconsole, fgrep, find, flock, free, fstrim, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, halt, hostname, id, ifconfig, ifdown, ifup, inetd, init,
        insmod, iostat, ip, ipaddr, iplink, iproute, iprule, iptunnel, kill, killall, killall5, ln, login, logname, ls, lsmod, lsof, md5sum, mkdir, mkfifo, mknod, mkswap, modprobe, more,
        mount, mpstat, mv, nbd-client, netstat, nice, nohup, nslookup, passwd, pidof, ping, ping6, pivot_root, pmap, poweroff, printenv, printf, ps, pstree, pwd, pwdx, readlink, realpath,
        reboot, renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole, setserial, sh, sha3sum, sleep, smemcap, sort, stat, stty, swapoff, swapon, switch_root, sync, sysctl, tail,
        tar, tee, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, ubiattach, ubidetach, ubimkvol, ubirmvol, ubirsvol, ubiupdatevol, umount, uname, uniq, unxz, unzip,
        uptime, vconfig, vi, wc, wget, whois, xargs, xz, xzcat, zcat
#

hier hat folgender Patch das "partielle" Problem mit extract_kernel und FRITZ.Box_7490_LabBETA.113.06.36-31504.image gefixt:

# diff -u modfs modfs.patched
extract_kernel()
{
         local src="$1" target="$2" tmp rc mp tmpdir
-        tar -xOf "$src" "$firmware_kernel_image" >"$target" 2>/dev/null
+        tmpdir=$(dirname "$target")
+        #tar -xOf "$src" "$firmware_kernel_image" >"$target" 2>/dev/null
+        tar -xvpf "$src" -C $tmpdir ./var/chksum ./var/tmp/kernel.image 2>/dev/null
+        mv $tmpdir/var/tmp/kernel.image "$target"
+        $tmpdir/var/chksum "$target" > /dev/null
         rc=$?

siehe auch # 300

 

[maulich]

Beide Varianten funktionieren. Grad getestet...Und in der Tat spart einem die Repack-Variante noch die Änderung im modfs bezüglich des filesystem.image...

sehr schön...jetzt kann es ja weitergehen...

merci!

 

[PeterPawn]

Ich habe die exakte Reihenfolge der Abarbeitung der einzelnen Funktionen jetzt nicht auf dem Schirm (hängt ja auch vom konkreten Aufruf des Skripts ab), aber die Stelle in "extract_filesystem" sieht identisch aus und sollte daher dieselben Probleme bereiten:

extract_filesystem()
{
        local src="$1" target="$2" tmp rc mp tmpdir
        debug "extract_filesystem: src=$src, target=$target"
        tar -xOf "$src" "$firmware_filesystem_image" >"$target" 2>/dev/null
        rc=$?
        if [ $rc -ne 0 ]; then
                rc=39
        fi
        debug "extract_filesystem: exiting, rc=$rc"
        return $rc
}

Das sollte also noch einmal exakt dieselbe Klippe darstellen ... insofern würde ich persönlich bei der Empfehlung des "Umpackens" bleiben, wenn man nicht ohnehin eine eigene Busybox (mit rc=0 auch bei "short read") benutzt.

 

[maulich]

Hmm...Das wiederum hat nun bei mir keinen Fehler gemacht...also auch ohne Änderungen...
Nachdem ich "FRITZ.Box_7490_LabBETA.113.06.36-31504.image" umgepackt hatte, konnte ich das unmodifzierte modfs-skript verwenden.

Busybox ist das von AVM...

 

[PeterPawn]

@splenditnet:
Kann es sein, daß Du noch eine ganz ganz alte Version von modfs verwendest?

Bei mir (ich schaue anschließend noch einmal auf den Server) sieht "extract_rootfs_from_wrapper" inzwischen so aus:

extract_rootfs_from_wrapper()
{
    local src="$1" target="$2" tmp rc mp tmpdir version kernelversion
    debug "extract_rootfs_from_wrapper: src=$src, target=$target"
    fstype=$(detect_image_filesystem "$src")
    rc=$?
    if [ $rc -eq 0 ]; then
        tmpdir="$(get_temp_dir)"
        if [ "$fstype" == "ext2" -o "$fstype" == "sqfs_dummy256_ext2" ]; then
            # ext2 image with AVM's dummy header
            mount_ext2_image "$src" "$tmpdir" "$fstype"
            rc=$?
        else
            mount "$src" "$tmpdir" 2>/dev/null
            rc=$?
            if [ $rc -ne 0 ]; then
                # try to extract with unsquashfs3, if this is a 3.xx kernel based
                # system without knowledge about SquashFS3 format while mounting
                kernelversion=$(uname -r)
                kernelversion=${kernelversion%%.*}
                if [ $kernelversion -eq 3 -a x"$fstype" == x"squashfs3" ]; then
                    unpack_squashfs "$src" "${target%/*}" "$rootfsname" 2>&1 >/dev/null
                    rc=$?
                    if [ $rc -eq 0 ]; then
                        mv "${target%/*}/$squashfsdirname/$rootfsname" "${target}"
                        rc=$?
                        rmdir "${target%/*}/$squashfsdirname"
                        remove_directory "$tmpdir"
                        debug "extract_rootfs_from_wrapper: exiting, rc=$rc"
                        return $rc
                    fi
                fi
            fi
        fi
        if [ $rc -ne 0 ]; then
            rc=40
        else
            cp -a "$tmpdir/$rootfsname" "$target"
            rc=$?
            if [ $rc -ne 0 ]; then
                rc=41
            fi
            umount "$tmpdir"
        fi
        remove_directory "$tmpdir"
    fi
    debug "extract_rootfs_from_wrapper: exiting, rc=$rc"
    return $rc
}

Wenn ich nicht absolut geschlafen habe, sollten die Versionen auf dem Server (siehe #1) das ebenso enthalten. Dieser "dummy header" ist ja einer der fundamentalen Unterschiede zwischen 06.35+ und den Versionen davor ... auch die Schwierigkeiten mit den diversen "losetup"-Versionen (Busybox und gnu-utils (unter /sbin/losetup auf einigen Versionen auch vorhanden) unterscheiden sich in den Parametern und der Möglichkeit der automatischen Auswahl eines Loop-Devices) sollten der Vergangenheit angehören. Aber ich kontrolliere die Versionen auf dem Server vorsichtshalber noch einmal ... manchmal ist es eben spät bei solchen Änderungen und ich werde ja auch nicht jünger.

EDIT: Es gab (absichtlich) unter dem Namen modfs.tgz (URL: http://yourfritz.de/modfs.tgz) noch die ältere Version, die sich nicht auf den Umgang mit 3er-Kernel und SquashFS4 versteht. Diese habe ich jetzt in "modfs_old.tgz" umbenannt, es gibt also keine "modfs.tgz" im Root-Verzeichnis des virtuellen Apache-Servers für "yourfritz.de" mehr. Die "modfs.tgz" im Unterverzeichnis "7490" bleibt erhalten, die aktualisierten drei Links aus #1 sind also weiterhin gültig. Das aktuelle Archiv (Stand 02.08.2015, es ist unter allen drei URL dasselbe File) hat den MD5-Hash "48a4c9a4799d284512176ad21ea588e0".

EDIT2: So, ich habe #1 am Anfang noch mit einem Hinweis auf dieses Problem (tar: short read) ergänzt und hierher verwiesen. Damit wäre das für mich (wenn es sich bei splenditnet nur um ein Versehen mit einer falschen Version handelte) erst einmal erledigt? Bitte keine "sehe ich auch so"-Posts ... nur Widerspruch wäre mir "genehm", falls jemand Argumente gegen meinen Standpunkt vorbringen möchte.

 

[splenditnet]

@PeterPawn:
update durchgeführt; nach: "wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x"
patchen von extract_kernel() und extract_filesystem()
läuft nun modfs durch.
Danke!

Gruß
Splenditnet

 

[eisbaerin]

Ab welcher FW auf der FB7490 funktioniert das modfs?

Ich wollte gerade von 113.06.05 "modfs update" machen, da erhalte ich folgenden Fehler:

/usr/sbin/blkid: invalid option -- p
blkid 1.0.0 (12-Feb-2003)
usage:  blkid [-c <file>] [-ghlLv] [-o format] [-s <tag>] [-t <token>]
    [-w <file>] [dev ...]
        -c      cache file (default: /etc/blkid.tab, /dev/null = none)
        -h      print this usage message and exit
        -g      garbage collect the blkid cache
        -s      show specified tag(s) (default show all tags)
        -t      find device with a specific token (NAME=value pair)
        -l      lookup the the first device with arguments specified by -t
        -v      print version and exit
        -w      write cache to different file (/dev/null = no write)
        dev     specify device(s) to probe (default: all devices)
 [COLOR="#F22222"]Fehler[/COLOR]
The specified message number 222 was not found at the language file for 'de'.

 

[PeterPawn]

Offenbar ist da noch eine recht alte Version von "blkid" im Image ... da die ganze Dateisystemerkennung (dafür wird blkid verwendet) erst später dazukam, hatte ich so eine alte Version nicht auf dem Schirm ... diese hier kennt weder die "p"-Option noch die Möglichkeit, an einem definierten Offset ("o"-Option) erst zu beginnen.

Daher funktionieren frühere (modfs-)Versionen (wenn sie schon "update" unterstützen, was die ersten auch nicht konnten) sicherlich auch mit der 06.05, da sie einfach keine Verwendung für "blkid" haben ... aber damit geht natürlich auch kein Update auf eine Version > 06.30.

Ich habe aber auch nicht die Absicht, da rückwärts irgendetwas zu ändern ... der Weg über ein Zwischenupdate mit 06.20 sollte als Lösungsansatz ausreichen. Ansonsten muß man eben noch ein passendes "blkid" (2.22.2 wäre aktuell und kennt alle notwendigen Parameter) auf die Box bringen und den Pfad dorthin an der einen definierten Stelle im Skript (irgendwo am Anfang, damit man genau auf solche Situationen reagieren kann) anpassen.

EDIT: Das mit der fehlenden Meldung für "222" im Sprach-File habe ich zur Kenntnis genommen, wird in der nächsten Version (so es eine geben sollte) mit ergänzt.

 

[eisbaerin]

Danke, habe mir eine neuere blkid aus der 113.06.20 besorgt.
Erst hatte ich in der FB7412 geschaut, da gibt es die Datei nicht, den Link unter /sbin aber schon.
Damit ging es dann:

[B]Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:
[/B]
das laufende System - Version 113.06.30 vom 15.07.2015 15:50:00, Dateisystem modifiziert am 08.10.15 22:20 (MTD2/MTD3)
das inaktive System - Version 113.06.05 vom 17, Dateisystem modifiziert am 01.01.70 01:00 (MTD0/MTD1)

 

[eisbaerin]

Du hast es bestimmt schon irgendwo geschrieben, aber ich finde es nicht.

Gibt es auch die Möglichkeit den calllog wieder zu aktivieren?
Ich vermute nicht, sonst hättest du es bestimmt schon gemacht.

Mir gefällt an calllog, daß es den Namen aus dem Telefonbuch mit übergibt,
was der callmonitor leider nicht macht, obwohl es bestimmt möglich wäre.

 

[reinelektronik]

Hallo,

wenn ich versuche das Skript mit den letzten zwei Labors zu starten kommt es zu dieser Meldung:

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: 113.06.36--31437

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/TTI-MSA-USB2-0MD-01/Firmware.image' wird als Quelle f├╝r die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... Fehler
Beim Extrahieren des Kernel-Abbilds aus der Firmware-Datei ist ein Fehler aufgetreten.
#
woran liegt das und was kann ich machen damit es klappt.

Grüße Reiner

 

[PeterPawn]

woran liegt das und was kann ich machen damit es klappt.

Ad hoc würde ich sagem, die Lektüre von #305 sollte helfen oder auch das Lesen des neuen Hinweises vom 03.10. in #1.

Sollte das nicht zum Erfolg führen, braucht es das Debug-Protokoll (der Verweis auf den Beitrag, wie man das erstellen kann, steht ebenfalls in #1), um da tiefer einzusteigen.

 

[reinelektronik]

Hallo,

beim ausführen des angepassten Einzeilers aus #305 kam zwar noch eine Fehlermeldung aber mit dem erstellten Image konnte dann das Skript ohne Fehler durchlaufen.

Danke Reiner

 

[eisbaerin]

Ich erlaube mir mal zu Antworten:
Da hast du #305 nicht genau gelesen, denn:

Wahrscheinlich trifft es die Stelle mit dem Auspacken von "filesystem.image" dann aber noch einmal genauso ...

Und dann geht es auch ...
Also deine Fragen hätte ich mir gar nicht getraut zu stellen, da sie gerade vor kurzem ausführlichst behandelt und positiv mit mehreren Lösungen ausdiskutiert wurde.

Daß ich aber keine Antwort auf meine calllog Frage bekomme???

 

[PeterPawn]

@eisbaerin:
Sorry, übersehen ... das "telefon"-Binary enthält zwar noch die Zeichenketten für "/var/flash/calllog" und sogar das vermutlich dafür verwendete "/usr/bin/mkconfigfile" ist noch drin, aber das ist wohl "stillgelegt", wenn der Code überhaupt noch existiert. Das ist jedenfalls nicht nur ein Skript, was da fehlt oder anders arbeitet, das ist in den Tiefen eines AVM-(C-)Programms.

Wenn der Code noch vorhanden ist und nur über eine bedingte Verzweigung umgangen wird, könnte man event. das Binary patchen, aber den Aufwand sehe ich in keinem Verhältnis zum möglichen Nutzen. Da ist es dann einfacher, den "callmonitor" aus Freetz zu nehmen und etwas anzupassen, damit er (wenn das noch nicht der Fall sein sollte) auch ohne Freetz laufen kann. Wenn man auf solche Späße wie ein GUI zur Konfiguration verzichtet und eher auf Textdateien setzt, sollte das nicht so ein riesiger Aufwand sein. Das Hauptproblem sehe ich darin, daß man dann die Busybox zwangsweise tauschen muß oder irgendein anderes "netcat"-Äquivalent auf die Box bringen muß, damit man sich an den Port 1012 hängen kann.

EDIT:
Ich mache jetzt mal einen Test und benenne den gesamten Thread um. Es geht ja schon lange nicht mehr um die "debug.cfg" und 06.20 ... ich nehme mal "modfs" mit in den Titel auf, damit es leichter gefunden und identifiziert werden kann.