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

[XJIOP]

Thanks PeterPawn! it works fine :bier:

 

[palast]

Mal ein paar Nachfragen, weil mir das auch nach Studium des Threads nicht so ganz klar wird:
Wie kann ich erreichen, dass beim Update von einer 6.24er Firmware der 7490 auf die neue 6.30er die Telnet-Funktion bzw. debug.cfg/rc.use nicht hopps gehen?
Kann ich eine erfolgreich mit diesem Skript veränderte Firmware (debug.cfg - rc.user) einfach updaten, oder muss ich jedesmal das Skript nach einem Firmware-Update neu aufrufen und wie mache ich Letzteres, wenn Telnet nicht mehr funktioniert?

 

[KiRKman]

Du musst bei jeder neuen Version das Update über das Script durchführen - und nicht regulär über die Web-Oberfläche. Denn sonst würden jegliche Modifikationen wieder verschwunden sein.

Bei den Labor-Versionen, die ja häufiger neu erscheinen, mache ich es so:

• Labor herunterladen, ZIP entpacken und die Image-Datei auf einen USB-Speicher kopieren, der an der FRITZ!Box angeschlossen ist
• modfs auf die FRITZ!Box herunterladen und entpacken
• modfs mit dem "update"-Parameter starten und alles erledigen lassen
• Reboot

Die Kommandos dafür:

mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x
./modfs update /var/media/ftp/Samsung-S2Portable-01/fw/labor.image
reboot

Das Script wird frisch nach /var/mod heruntergeladen (und entpackt); das Verzeichnis ist nach einem Reboot natürlich wieder weg.
Den Pfad zum USB-Speicher muss dann jeder selber anpassen. Irgendwo muss das Image ja liegen, so dass das Script es entpacken kann. Dies erfolgt übrigens in den internen Macronix-Flash der Box (/var/media/ftp/123456), der aber nach dem Vorgang aufgeräumt wird.

Verwendet man lediglich Release-Versionen, reicht es glaube ich aus, das Script nur mit dem Parameter "update" ohne alles weitere auszuführen, weil dann die aktuelle Firmware automatisch vom AVM-FTP heruntergeladen und verwendet wird.

Wenn Telnet bei Dir aufgrund einer neueren Firmware-Version schon nicht mehr funktioniert, musst Du zuerst ein Pseudo-Image verwenden, um Telnet temporär wieder zu aktivieren. Tante Google hilft da weiter:
http://bfy.tw/1qFh

 

[palast]

Verwendet man lediglich Release-Versionen, reicht es glaube ich aus, das Script nur mit dem Parameter "update" ohne alles weitere auszuführen, weil dann die aktuelle Firmware automatisch vom AVM-FTP heruntergeladen und verwendet wird.

Danke für die prompte und ausführliche Antwort.

Wo kommt der Parameter "-update" konkret hin?
Muss man beim Weg über Update über den FTP-Server von AVM gehen oder kann man das Image auch lokal auf dem Stick haben?

 

[KiRKman]

./modfs update

Einfach so, ohne alles. Dann sehen und staunen Kommt später die Frage, ob die Telnet-Modifikation gewünscht ist, diese natürlich mit "j" beantworten.

Man kann das Image immer auch auf dem Stick haben, muss also nicht über den FTP-Server von AVM gehen. Die Labor-Versionen müsste man sowieso vorher manuell runterladen und bereitstellen.

 

[PeterPawn]

Einfach schon mal als möglichen Ansatz vor der Frage der eisbaerin, ob man das auch bei einer 7412 irgendwie hinbekommt:

Meines Wissens sind die Angaben zum verbauten Hauptspeicher bisher unvollständig (zumindest in der Liste von qwertz.asdfgh und die enthält m.W. die aktuellsten Angaben). Wenn da auch wenigstens 128 MB drin sind und mangels Telefonie einiges nicht vorhanden ist, sollte es entweder sogar DavFS im Image schon geben oder man kann es auch ohne großen Aufwand aus einem Image für eine andere VR9-Box gewinnen. Wenn man das dann auf einen lokalen WebDAV-Server losläßt, hat man schon mal ein halbwegs performantes Dateisystem (zumindest besser als keines). Andere FUSE-basierte Dateisysteme (FUSE ist sicherlich im Kernel vorhanden, müßte man aber ggf. verifizieren, davon hängt natürlich dann davfs2 an sich auch ab) kämen auch noch in Frage ... aber am Ende stellt sich (solange es sich nur um modfs dreht) dann tatsächlich die Frage, ob es nicht einfacher ist, das auf einer anderen Maschine (ggf. sogar auf einer "größeren" FRITZ!Box) machen zu lassen. Mit steigendem Aufwand zum Einrichten der Umgebung nimmt natürlich der Ertrag der "Linux-losen" Ausführung (das meint natürlich nur "ohne dedizierte Linux-Maschine wie bei Freetz") entsprechend ab. Vielleicht kann man ja mal darüber nachdenken, das Aus- und Einpacken vom Modifizieren wieder zu trennen. In meinem ersten Entwurf waren das ja alles noch einzelne Arbeitsschritte ... es hat bloß kein Mensch die Anleitung meinerseits dazu verstanden (kann ich nach ca. 1 Jahr selbst nicht mehr) und daher habe ich dann alles in ein einzelnes Skript gepackt.

 

[eisbaerin]

Ich habe meine Frage im anderen Thema gelöscht und wollte sie gerade hier stellen, aber du warst schneller.

(zumindest in der Liste von qwertz.asdfgh und die enthält m.W. die aktuellsten Angaben

Für dich vielleicht, ich habe ihm aber gestern die neusten Informationen für die FB7412 zukommen lassen, die müssen aber noch von ihm eingepflegt werden.
Aber frage mich bitte, wenn du etwas brauchst.

128MB sind drin, sogar 2 mal, RAM und NAND

mangels Telefonie einiges nicht vorhanden ist

Doch Telefonie ist vorhanden! Genau wie in der FB7362SL!

Es fehlt hauptsächlich der USB-Port.
In der GUI fehlt der NAS, aber die 20 MB im /var/media/ftp sind vorhanden und schon von mir genutzt.

z.Z. habe ich die FW 06.21 drauf, wo noch telnet geht, aber die debug.cfg fehlt.
Es ist auch noch keine 2. FW drauf, da der Eintrag im environment noch fehlt.

Um SSH und anderes zu starten, gehe ich z.Z. immer per telnet drauf und mache dann:

/var/media/ftp/debug.cfg

 

[qwertz.asdfgh]

... die müssen aber noch von ihm eingepflegt werden.

Sorry hab gerade viel zu tun, wird aber noch diese Woche, versprochen, frei nach dem Motto:
"Was du kannst verschieben auf morgen, verschiebe auf übermorgen..." :weg:

Habe jedenfalls eine "ToDo-Liste" in Beitrag #1 hinzugefügt damit man wenigstens die geplanten Änderungen schon einmal vorausahnen kann.

 

[PeterPawn]

@eisbaerin:
Du müßtest halt mal in der Stock-Firmware nachschauen, was da so an Netzwerk-Komponenten enthalten ist.

Wenn tatsächlich /sbin/mount.davfs vorhanden ist, könnte man die bisherige Beschränkung auf lokale Filesysteme mit einem optionalen Parameter aufheben und ein (ausreichend schnelles, weil lokal im LAN vorhandenes) DAV-"Laufwerk" als Arbeitsverzeichnis benutzen. Alles andere braucht dann eben wieder zusätzliche Binaries, die extern übersetzt und mit "modfs" zusammen ins NAND-FS kopiert werden müßten. Da wäre das externe Modifizieren (mit Freetz) dann wieder einfacher und ich würde die 7412 außen vor lassen.

Wenn die 7412 auch die zwei Partition-Sets hat, solltest Du erst einmal das zweite mit einem System versehen (notfalls zu Fuß, die Reihenfolge der Kommandos würde ich bei Bedarf auflisten), damit Du eine Umschaltung vornehmen kannst, falls beim "Basteln" etwas schief geht. Du kannst aber auch einfach ein AVM-Image für die aktuell installierte Version nehmen, auf die Box kopieren und nach /var auspacken und die dort enthaltene /var/install von Hand aufrufen. Dabei wird dann auch dieselbe Version in die anderen Partitionen kopiert und auch gleich die Environment-Variable gesetzt, wenn Du nach erfolgter Modifikation der /var/post_install durch den Aufruf von /var/install die Box einmal neu startest. Erst dann würde ich mit irgendwelchen Experimenten beginnen, es erspart im Falle eines Problems einfach das Recovern ...

 

[eisbaerin]

Also /sbin/mount.davfs gibt es nicht.
Alles andere bitte genau mit Befehlen mich fragen, ich habe doch fast keine Ahnung.
Oder ich mache für dich mal eine telnet Zugang.

zwei Partition-Sets hat sie:

7412# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                49152     17660     31492  36% /wrapper
/dev/loop0               15232     15232         0 100% /
tmpfs                    57412       800     56612   1% /var
tmpfs                    57412         8     57404   0% /dev
/var/dev/nand            18176      1160     17016   6% /var/media/ftp

7412# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 011c0000 00020000 "nand-filesystem"
mtd6: 00040000 00020000 "urlader"
mtd7: 00400000 00020000 "nand-tffs"

7412# cat /proc/partitions
major minor  #blocks  name

   7        0      15220 loop0
  31        0       4096 mtdblock0
  31        1      49152 mtdblock1
  31        2       4096 mtdblock2
  31        3      49152 mtdblock3
  31        4       2048 mtdblock4
  31        5      18176 mtdblock5
  31        6        256 mtdblock6
  31        7       4096 mtdblock7

Ja, ein zweites System mache ich drauf.

 

[PeterPawn]

@eisbaerin:
Wenn es keinen DAV-Client auf der Box gibt, fällt mir auch nicht mehr so viel ein, wie man da den notwendigen Speicher in einer 7412 "organisieren" kann oder soll. Alles das, was zusätzliche Binaries auf der Box braucht, um externen Storage einzubinden, ist ein viel zu großer Aufwand im Vergleich zu einer Modifikation der Firmware mit Freetz.

Irgendwann will er13 ja mal einen "kompletten Ablauf" von Entpacken, Modifizieren und Neupacken auch in Freetz aufnehmen ... wenn man das Aufrufformat meiner modscripts dafür adaptiert oder einfach einen Wrapper aufruft, der diese abarbeitet (wie das aussehen kann, ist ja in modfs schon enthalten), dann kann man wieder auf dieselbe Basis zurückgreifen.

Die letzte Chance, die ich noch sehen würde, wären "network block devices" (ging zumindest bei der 7490 mal), aber die brauchen auch wieder einen passenden Server (i.d.R. unter Linux) und dann kann man auf so einer Maschine auch gleich den kompletten Vorgang mit allen Modifikationen laufen lassen. modfs war/ist ja in erster Linie für Leute gedacht, die keine eigene Freetz-Installation haben/wollen und sich davon bereits überfordert sehen. Wenn jetzt für die Modifikation wieder eine andere Linux-Maschine als externer Storage-Server benötigt wird, konterkariert das ja eines der Grundanliegen.

 

[thecoder2012]

Wäre ein modfs bzw. dauerhafter Zugang für 6490 auch denkbar?

Im Test ging telnetd (busybox) mit anderem Port 223 problemlos per Formular /cgi-bin/firmwarecfg, natürlich die Session im HTML-Code per Inspect Element ersetzen (sonst landet man auf der Loginpage), dann ganz normal bestätigen das man keine Original Firmware aufspielen will und das übliche Firmwareskript nutzen damit man Telnet aktiviert ähnlich wie bei 7390. Port 23 ist auf 6490 wohl gesperrt. Getestet an einer 6490 mit 6.24 als Firmware.

Mir ist allerdings mehrfach die Box nach einiger Zeit gecrasht und/oder Telnet hat sich zurückgesetzt aber war immer eine ganze Weile offen und nutzbar. Ggf. zweite Telnetsession eröffnen wenn im ersten Terminal zu viele Warnungen erscheinen.

Man müsste wohl ein leicht stärker angepasstes Skript nutzen, nicht nur den Port auf 223 ändern. Das Skript vorher natürlich mit 7390 getestet.

 

[PeterPawn]

Die 6490 ist generell anders aufgebaut als die anderen Boxen. Es gibt zwei "VMs" (allerdings auf realen Kernen) mit jeweils einem Dual-Core-Prozessor, einer mit ARM-, der andere mit ATOM-Architektur (stinknormales x86). Diese Systeme kommunizieren über einen internen RPC-Mechanismus (mailbox) miteinander. Die Aufgaben nach außen (in Richtung User) werden zwischen ARM- und ATOM-Teil verteilt, auf dem ATOM läuft das komplette NAS und die Bedienung des NAND-Flashs unter /var/media/ftp als ext4-Partition sowie der TV-Empfang. Der Rest läuft eigentlich auf dem ARM-Core.

Diese Aufteilung macht es etwas schwieriger, dort eine pauschale Aussage zu treffen, wie man eine solche Box (so sie einem denn auch tatsachlich gehört) modifizieren könnte. Dabei ist dann immer zwischen ARM- und ATOM-Core zu unterscheiden, auf beiden Kernen steht auch nicht jeweils ein identischer Satz an Kommandos zur Verfügung. Sollte sich jemand zur Modifikation einer 6490 durchringen, würde ich als "Angriffspunkt" das System in den ATOM-Partitionen empfehlen, da dieses mit normalen (32-Bit- !!!)-Binaries für x86 arbeiten kann und auch das dort vorhandene Filesystem auf dieser Basis mit den ganz normalen Tools für SquashFS4 in LE-Kodierung bearbeitet werden kann.

Eigentlich will ich mich aber nicht weiter zur 6490 in der Öffentlichkeit äußern ... allerdings bauen einige Sachen für die 7490 (insb. das dort verwendete SquashFS4 mit BE) durchaus auf früheren Erkenntnissen mit einer 6490 auf. Das war zum Thema "Modifikation 6490" vorerst das Letzte, was ich von mir gebe ... ich bitte um Verständnis.

 

[carlos]

Hallo,
Ich wollte heute wie gewohnt das update auf die neue Version FRITZ.Box_7490_LabBETA.113.06.36-31504 machen.
Leider erfolglos mit folgendem Fehler:

2015-10-03 00:36:12.010 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2015-10-03 00:36:12.038 - check_prerequisites: filesystem device is /dev/mtdblock1
2015-10-03 00:36:12.103 - progress: mode=3, msg= OK
2015-10-03 00:36:12.166 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2015-10-03 00:36:12.195 - check_prerequisites: alternative filesystem device is /dev/mtdblock3
2015-10-03 00:36:12.259 - progress: mode=3, msg= OK
2015-10-03 00:36:12.324 - progress: mode=1, msg=  berpr  fen des zur Verf  gung stehenden Speicherplatzes im RAM ...
2015-10-03 00:36:12.351 - check_free_tmpfs: wanted=25165824, needed=10485760
2015-10-03 00:36:12.384 - check_free_tmpfs: exiting, rc=0
2015-10-03 00:36:12.448 - progress: mode=3, msg= OK
2015-10-03 00:36:12.512 - progress: mode=1, msg=  berpr  fen des freien Speicherplatzes f  r das Auspacken des Dateisystems ...
2015-10-03 00:36:12.538 - find_free_storage_space: needed=140509184, accept=
2015-10-03 00:36:12.700 - get_nand_mountpoint: location=/var/media/ftp
2015-10-03 00:36:12.734 - check_free_nand: size=140509184, nand=/var/media/ftp, free=423079936
2015-10-03 00:36:12.755 - find_free_storage_space: /var/media/ftp:423079936
2015-10-03 00:36:12.774 - find_free_storage_space: exiting, rc=0
2015-10-03 00:36:12.839 - progress: mode=3, msg= OK
2015-10-03 00:36:12.858 - check_prerequisites: exiting, rc=0
2015-10-03 00:36:13.569 - modfs: source=file_update
2015-10-03 00:36:13.598 - modfs: firmware update file=/var/media/ftp/Medion-USBFlashDrive-01/fw/FRITZ.Box_7490_LabBETA.113.06.36-31504.i
2015-10-03 00:36:13.668 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/Medion-USBFlashDrive-01/fw/FRITZ.Box_7490_LabBETA.1
6.36-31504.image' wird als Quelle f  r die Aktualisierung genutzt.
2015-10-03 00:36:13.691 - find_free_space: wanted=32M, order=tmpfs nand storage
2015-10-03 00:36:13.719 - check_free_tmpfs: wanted=33554432, needed=33554432
2015-10-03 00:36:13.751 - check_free_tmpfs: exiting, rc=0
2015-10-03 00:36:13.770 - find_free_space: tmpfs=/var/tmp
2015-10-03 00:36:13.789 - find_free_space: exiting, rc=0
2015-10-03 00:36:13.810 - get_working_directory: /var/tmp
2015-10-03 00:36:13.830 - modfs: working directory=/var/tmp
2015-10-03 00:36:13.862 - modfs: image directory=/var/tmp/1443825373
2015-10-03 00:36:13.923 - progress: mode=1, msg=Extrahieren des neuen Kernel-Images aus dem Firmware-Image ...
2015-10-03 00:36:13.943 - extract_kernel: src=/var/media/ftp/Medion-USBFlashDrive-01/fw/FRITZ.Box_7490_LabBETA.113.06.36-31504.image, ta
=/var/tmp/1443825373/kernel.image
2015-10-03 00:36:14.001 - extract_kernel: exiting, rc=62
2015-10-03 00:36:14.063 - progress: mode=3, msg= Fehler
2015-10-03 00:36:14.124 - cleanup: running cleanup from file /var/tmp/5527_filelist_1443825370
2015-10-03 00:36:14.143 - rm -r /var/tmp/1443825373

Der Fehler sagt mir leider nichts.

Gruß

Carlos

 

[PeterPawn]

Das kann eigentlich nur "zuwenig Speicherplatz" sein ... ich würde es nach einem Neustart erneut probieren (der Kernel wird ins tmpfs (image directory) entpackt bei Dir).

Hilft auch das nicht, einige Prozesse der FRITZ!Box vorher stoppen ... zu "prepare_fwupgrade" steht irgendwo weiter vorne in diesem Thread etwas. Bei mir läuft das Update auch mit der aktuellen Version durch (zumindest über die Stelle mit dem Fehler bei Dir hinaus).

 

[carlos]

Hat leider nicht geholfen.
Ich habe Neustart probiert, dann einige processe gekillt.
Speicher sieht so aus

# free
             total         used         free       shared      buffers
Mem:        240048       108332       131716            0        17804
-/+ buffers:              90528       149520
Swap:            0            0            0

Sollte eigentlich reichen, oder?
Kommt aber der gleiche Fehler.
Na ich probier mal weiter.
Gruß
Carlos

 

[maulich]

Bei mir kommt der Fehler auch vor...versuche ich, im laufenden 113.06.36-31437 das 31504er image direkt mit tar zu entpacken bekommen ich folgende Ausgabe:

./var/
./var/regelex
./var/install
./var/info.txt
./var/tmp/
./var/tmp/filesystem.image
./var/tmp/kernel.image
./var/chksum
./var/signature
tar: short read

Auch ein Neustart der FB7490 bringt keine Besserung...
wenn ich versuche, daß Image auf einem Linux-Rechner zu entpacken, kommt der Fehler nicht...packe ich das Image dann mit tar auf dem Rechner neu und versuche es wieder auf der FB zun entpacken kommt hier ein neuer Fehler (rc=222)..hm...

 

[splenditnet]

Hallo zusammen,
der Fehler wird bei carlos durch die Funktion extract_kernel ausgeworfen

cat modfs
SNIP
# extract kernel image from firmware image
# $1 - source firmware image
# $2 - target file name and path (path has to be a valid directory)
#
extract_kernel()
{
        local src="$1" target="$2" tmp rc mp tmpdir
        tar -xOf "$src" "$firmware_kernel_image" >"$target" 2>/dev/null
        rc=$?
        if [ $rc -ne 0 ]; then
                rc=62
        fi
        return $rc
}

so wie es aussieht haben wir hier wieder das Problem "tar: short read"

# tar -xOf /var/media/ftp/SanDisk-CruzerFit-01/download/FB7490-06.36-31504/FRITZ.Box_7490_LabBETA.113.06.36-31504.image ./var/tmp/kernel.image > /var/tmp/1443869431/kernel.image
tar: short read
# echo $?
1
#

next step: abklären, ob wir hier ein kosmetisches Problem haben, spricht das ausgepackte Kernel.Image ist OK und nur die Verpackung "FRITZ.Box_7490_LabBETA.113.06.36-31504.image" ist so, dass tar und modfs hier Fehler auswirft.

Gruß
Splenditnet

 

[maulich]

Habe gerade mit fwmod aus freetz das Image entpackt...das ergab folgendes:

~/src/freetz-devel$ ./fwmod -u -d unpacked_firmware FRITZ.Box_7490_LabBETA.113.06.36-31504.image

STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...unpacking update image
unpacking filesystem image
    Filesystem on unpacked_firmware/original/filesystem_core/filesystem_core.squashfs is xz compressed (4:0)
    Parallel unsquashfs: Using 1 processor
    3609 inodes (4167 blocks) to write
    created 2992 files
    created 232 directories
    created 530 symlinks
    created 87 devices
    created 0 fifos
unpacking var.tar
done.

detected firmware 7490_de 113.06.36-BETA rev31504 (01.10.2015 13:52:52)

FINISHED

Die Datei "/src/freetz-devel/unpacked_firmware/original/kernel/kernel.raw" ist 2505984 Bytes groß...

hilft das irgendwie weiter?

 

[splenditnet]

Hallo zusammen,
anbei Statusupdate zu Problem "tar-Befehl wirft beim Auspacken von FRITZ.Box_7490_LabBETA.113.06.36-31504.image die Meldung "short read" aus und setzt Return-Code 1"

die wichtigen Dateien "./var/tmp/filesystem.image", "./var/tmp/kernel.image"
sind sauber im FRITZ.Box_7490_LabBETA.113.06.36-31504.image enthalten
und können problemlos ausgepackt werden;

# tar tvpf /var/media/ftp/SanDisk-CruzerFit-01/download/FB7490-06.36-31504/FRITZ.Box_7490_LabBETA.113.06.36-31504.image
drwxr-x--- 0/0         0 2015-10-01 13:53:20 ./var/
-r-xr-x--- 0/0    283844 2015-09-15 12:03:05 ./var/regelex
-rwxr-x--- 0/0     34088 2015-10-01 13:53:20 ./var/install
-rwxr-x--- 0/0      2795 2015-10-01 13:53:20 ./var/info.txt
drwxr-x--- 0/0         0 2015-10-01 13:53:20 ./var/tmp/
-rw-r----- 0/0  22937608 2015-10-01 13:53:20 ./var/tmp/filesystem.image
-rw-r----- 0/0   2505992 2015-10-01 13:53:20 ./var/tmp/kernel.image
-r-xr-x--- 0/0    278552 2015-09-15 12:03:05 ./var/chksum
-rw-r----- 0/0       128 2015-10-01 13:53:20 ./var/signature
tar: short read
# tar xvpf /var/media/ftp/SanDisk-CruzerFit-01/download/FB7490-06.36-31504/FRITZ.Box_7490_LabBETA.113.06.36-31504.image
./var/
./var/regelex
./var/install
./var/info.txt
./var/tmp/
./var/tmp/filesystem.image
./var/tmp/kernel.image
./var/chksum
./var/signature
tar: short read
#

Kontrolle:

# var/chksum var/tmp/filesystem.image 
read 0xc31bd1b2 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xc31bd1b2
Calculated checksum is C31BD1B2
Saved checksum is C31BD1B2
Checksum validation successful!

# var/chksum var/tmp/kernel.image
read 0x819d20bc MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x819d20bc
Calculated checksum is 819D20BC
Saved checksum is 819D20BC
Checksum validation successful!
#

Fazit/TL;DR:
Die Funktion extract_kernel wirft in diesem Fall eine "proactive" eine Fehlermeldung aus, da der tar-Befehl im tar-file eine von modfs nicht benötigte Datei vorfindet, die beim Auspacken per tar-Befehl "short read" meldet und Return-Code 1 setzt.
Das Problem ist somit aus modfs-Sicht durch Anpassung von extract_kernel Funktion aus Sicht lösbar.

Gruß
Splenditnet

Update: Fix fuer dieses Problem könnte so aussehen:

# vi modfs
SNIP
extract_kernel()
{
        local src="$1" target="$2" tmp rc mp tmpdir
        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=$?
        if [ $rc -ne 0 ]; then
                rc=62
        fi
        return $rc
}