[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

[eisbaerin]

Ich habe mal die SquashFS-Tools für "armv7l" auch mit der Freetz-Toolchain (genauer mit meinem Fork) gebaut und statisch gelinkt.

Danke, gehen auch auf der 7530.

Gestern/Heute hatte ich Probleme beim Modifizieren.
Ich mache das ja immer auf der 7580. Ging auch bisher mit FW 7.12 sehr gut.
Jetzt hat die 7580 aber vor kurzem die FW 7.19 bekommen und da gehen einige modscrips plötzlich nicht mehr.
Konkret sind es die, welche "patch" verwenden. z.B. mod_prefer_fonnumber_name
Der Befehl "$home/bin/$HWRevision/busybox patch" klappt nicht mehr.
Wenn ich dort das ganze Vorgeplänkel weg lasse und nur "patch" schreibe geht es bei mir.
Dann habe ich mich auf die Fehlersuche begeben.
Erst dachte ich es liegt an der Variblen $home, weil ich das ganze modfs jetzt in den NAS verschoben habe, damit ich es nicht bei jedem Neustart neu runter laden muß. (ich will ja deinen Zähler nicht überlasten )
Aber das war es nicht.
Nach langem Suchen habe ich gefunden, daß die Variable $HWRevision dort 000 hat.
Mit 000 wird dann aber /bin/busybox aufgerufen, welche aber das Applet patch nicht hat.
Auf der Console zeigt die Variable aber korrekt 225, nur in dem modscript kommt es falsch.
Irgend etwas muß sich da wohl mit dem neuen Kernel verändert haben.
Wenn du noch ein paar Tests/Auskünfte brauchst, mache ich das gerne.

EDIT:
Jetzt weiß ich ich warum es mit der FW 7.12 ging.
Das war ja ein freetz, und da hatte die /bin/busybox das patch mit drin.
Ich mache jetzt in dem run_modscripts ein "#" vor die Zeile:
export HWRevision="000"
Das sollte gehen, sonst schreibe ich die 225 da fest rein.
Warum setzt du da die Variable auf 000?

BTW:
Einige andere Scripts mußte ich bei mir auch ändern.
Das "local" darf seit der 7.20 nicht mehr einfach so in einem Script stehen, nur noch in einer Funktion.

##########################################################

Anschließend ruft man /var/install auf und betet, daß alles gut gehen möge ...

Ich habe das heute mal so bei einer 7490 gemacht.
30 min gebetet, aber es passierte nichts. Im gui_bootmanager sah ich aber schon die neue FW in der inaktiven Partition.
Also Stecker gezogen und neu booten lassen.
Sie war aber immer noch auf der alten FW. Also selber auf die andere Partition umgestellt und neu gebootet.
Dann erst kam sie mit der neuen FW hoch.

Ist das normal so?
Ich dachte, das macht sie alles alleine, genau so wie bei einem normalen Update.

 

[PeterPawn]

Das "local" darf seit der 7.20 nicht mehr einfach so in einem Script stehen, nur noch in einer Funktion.

Das ist eine Änderung in der BusyBox-Shell - mit neuer AVM-Version kommt auch eine neue(re) BusyBox.

Das ist einer der Gründe, warum es im "modfs"-Paket immer noch ziemlich alte Versionen gibt - ich habe keine Lust, alte Skript-Dateien noch einmal anzupassen, weil sich die "ash"-Syntax geändert hat.

Neue berücksichtigen das gleich - ein "local" ist eben nicht Bestandteil des POSIX-Standards und da, wo man es tatsächlich brauchen würde, setze ich dann eben nicht auf einen "Block" (das ist eine Funktion, deren Body in geschweifte Klammern eingeschlossen wird und die mittels "return" (zumindest bei explizitem Aufruf) enden kann), sondern auf eine "Sub-Shell" - hierbei wird der Body in runde Klammern eingeschlossen und quasi in einer eigenen Shell-Instanz ausgeführt, wo alle Variablen automatisch lokal sind.

Das hat Vor- und Nachteile, so kann man auf diesem Weg eben auch keine Variablen in der aufgerufenen Funktion setzen, die man später erst auslesen will - daher geben die dann fast immer etwas auf STDOUT zurück, was einer Variablen im Aufrufer-Kontext zugewiesen wird: var="$(function arg1 arg2)". Die Verwendung von geschweiften oder runden Klammern um den Body so einer Funktion ist also auch nicht "frei Schnauze", das ist schon mit Bedacht gewählt, vor allem, weil man aus einer Sub-Shell besser mittels exit n ein negatives Resultat signalisiert, als mit return.

Ansonsten mault eben die "ash" seit einiger Zeit herum, wenn es außerhalb einer Funktion ein "local" gibt, während es innerhalb noch klaglos akzeptiert wird (von vielen Shells, selbst von der "dash", die sich sonst praktisch 1:1 am POSIX-Standard entlanghangelt) und auch den gewünschten Effekt hat.

Wenn Du die Liste der Fundstellen hast (da reicht auch ein "diff" Deiner Korrekturen gegen die originalen Dateien), patche ich das aber gerne noch in die vorhandenen Dateien hinein - nur will ich da jetzt nicht nach allen Vorkommen von "local" schauen, ob die nun Probleme machen oder nicht.

Denn wenn ich versuche, das mit der "ash" automatisch finden zu lassen:

vidar:/home/GitHub/modfs/modscripts $ for f in *; do ../../busybox/busybox.desktop ash -n $f; done
vidar:/home/GitHub/modfs/modscripts $ ../../busybox/busybox.desktop ash -n -c "set +o"
set +o errexit
set +o noglob
set +o ignoreeof
set +o monitor
set -o noexec
set +o xtrace
set +o verbose
set +o noclobber
set +o allexport
set +o notify
set +o nounset
set +o vi
set +o pipefail
vidar:/home/GitHub/modfs/modscripts $ ../../busybox/busybox.desktop
BusyBox v1.33.0.git (2020-07-19 16:05:11 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --show SCRIPT
   or: busybox --install [-s] [DIR]
   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:
        [, [[, acpid, add-shell, addgroup, adduser, adjtimex, arch, arp, arping, ash, awk, base64, basename, bc, beep, blkdiscard, blkid, blockdev, bootchartd, brctl, bunzip2, bzcat, bzip2, cal, cat, chat, chattr, chgrp, chmod, chown,
        chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd,
        dnsdomainname, dos2unix, dpkg, dpkg-deb, du, dumpkmap, dumpleases, echo, ed, egrep, eject, env, envdir, envuidgid, ether-wake, expand, expr, factor, fakeidentd, fallocate, false, fatattr, fbset, fbsplash, fdflush, fdformat,
        fdisk, fgconsole, fgrep, find, findfs, flock, fold, free, freeramdisk, fsck, fsck.minix, fsfreeze, fstrim, fsync, ftpd, ftpget, ftpput, fuser, getopt, getty, grep, groups, gunzip, gzip, halt, hd, hdparm, head, hexdump, hexedit,
        hostid, hostname, httpd, hush, hwclock, i2cdetect, i2cdump, i2cget, i2cset, i2ctransfer, id, ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, insmod, install, ionice, iostat, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink,
        ipneigh, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd, last, less, link, linux32, linux64, linuxrc, ln, loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lsof,
        lspci, lsscsi, lsusb, lzcat, lzma, lzop, makedevs, makemime, man, md5sum, mdev, mesg, microcom, mim, mkdir, mkdosfs, mke2fs, mkfifo, mkfs.ext2, mkfs.minix, mkfs.vfat, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more,
        mount, mountpoint, mpstat, mt, mv, nameif, nanddump, nandwrite, nbd-client, nc, netstat, nice, nl, nmeter, nohup, nologin, nproc, nsenter, nslookup, ntpd, nuke, od, openvt, partprobe, passwd, paste, patch, pgrep, pidof, ping,
        ping6, pipe_progress, pivot_root, pkill, pmap, popmaildir, poweroff, powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath, reboot, reformime,
        remove-shell, renice, reset, resize, resume, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run-init, run-parts, runlevel, runsv, runsvdir, rx, script, scriptreplay, sed, sendmail, seq, setarch, setconsole, setfattr,
        setfont, setkeycodes, setlogcons, setpriv, setserial, setsid, setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, showkey, shred, shuf, slattach, sleep, smemcap, softlimit, sort, split, ssl_client, start-stop-daemon, stat,
        strings, stty, su, sulogin, sum, sv, svc, svlogd, svok, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tc, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch, tr,
        traceroute, traceroute6, true, truncate, ts, tty, ttysize, tunctl, ubiattach, ubidetach, ubimkvol, ubirename, ubirmvol, ubirsvol, ubiupdatevol, udhcpc, udhcpc6, udhcpd, udpsvd, uevent, umount, uname, unexpand, uniq, unix2dos,
        unlink, unlzma, unshare, unxz, unzip, uptime, users, usleep, uudecode, uuencode, vconfig, vi, vlock, volname, w, wall, watch, watchdog, wc, wget, which, who, whoami, whois, xargs, xxd, xz, xzcat, yes, zcat, zcip

, passiert da gar nichts, obwohl das eine brandneue 1.33.0 ist, die ich vor drei Tagen erst übersetzt habe.

Beim Aufruf mit "-n" sollte einfach die Syntax gecheckt werden - offenbar wird dabei die Frage, ob da ein "local" außerhalb einer Funktion steht, aber nicht bemängelt (wenn's das in den Skripten gibt, was Du ja schreibst).

Warum setzt du da die Variable auf 000?

Weil ja nicht gesagt ist, daß das Skript auf einer FRITZ!Box aufgerufen wird, wo "HWRevision" dann den Weg zu einer "gültigen" BusyBox weist - und das ist nun mal Bestandteil des verwendeten Dateinamens für die BusyBox. Also wird das - nur bei Verwendung von "run_modscripts" - auf "000" gesetzt und der Benutzer ist dafür zuständig, dafür zu sorgen, daß die automatisch gefundene BusyBox (a) zur vorhandenen Plattform paßt und (b) den notwendigen Umfang an Kommandos kennt. Die von mir bereitgestellten BusyBox-Binaries geben alle ihre Konfiguration preis und zusätzlich liegt i.d.R. (auch beim "modfs": https://github.com/PeterPawn/modfs/tree/master/bin/common) diese als Textdatei auch noch einmal neben den Binärdateien, so daß man sich problemlos die eigene bauen kann, die auch alles Notwendige enthält.

Und selbst wenn das Skript auf einer FRITZ!Box läuft, wo HWRevision gesetzt ist ... erstens muß die automatisch gefundene BusyBox nicht den notwendigen Funktionsumfang haben (so erging es Dir ja dann) und zweitens ist gar nicht sicher, daß diese HWRevision auch in der "modfs"-Verzeichnisstruktur enthalten ist - so sind z.B. die Dateien für x86 (Puma6->ATOM) und Vx180 (7390) zwar als Link vorhanden in der Struktur, aber die Dateien, auf die sie zeigen würden, fehlen - sie würden das Archiv nur unnötig aufblähen (das machen eigentlich die unterschiedlichen Versionen für 3.10.73 und 3.10.104/107 schon zur Genüge und häufig auch unnötigerweise).

Ich zitiere mich mal wieder selbst (die Hervorhebung fehlt im Original):

Ich habe mich jetzt mal breitschlagen lassen und ein Beispiel für ein Skript eingecheckt (das findet sich auch im TGZ-File, das man von yourfritz.de laden kann - es heißt "run_modscripts"), was als ersten Parameter den Verzeichnisnamen der entpackten AVM-Firmware erwartet und dann ALLE "modscript"-Files, die es in "modscripts/*" findet, in alphabetischer Folge der Dateinamen auf die entpackte Struktur losläßt und zwar ohne Berücksichtigung irgendwelcher "precheck"- oder "postcheck"-Aktionen und auch ohne Ansicht der Person (aka "x-flags") oder einer event. vorhandenen "custom_modscripts"-Datei.

Das Skript erwartet, daß es sich in der üblichen Verzeichnisstruktur befindet, die beim Auspacken der TGZ-Datei von yourfritz.de oder beim Klonen des GitHub-Repos entstehen würde - und zusätzlich muß noch eine aktuelle "BusyBox"-Implementierung verfügbar sein (weil die BB-Kommandos teilweise andere Syntax verwenden, als die "großen Versionen") und über den Suchpfad gefunden werden. Für diese BusyBox wird dann ein Symlink unter "bin/000/busybox" angelegt und danach wird diese für die Applets in den "modscript"-Files verwendet.

Wenn die "offizielle" BusyBox auf dem verwendeten System nichts taugt, würde ich auch nicht hingehen und an den Skript-Dateien ändern (schon aus Prinzip nicht, weil ein Fehler dabei schnell mal zu "falschen Verdächtigungen" führt - was peinlich sein kann) - stattdessen würde ich mir ein Verzeichnis anlegen an einer "beschreibbaren" Stelle, da einen Symlink zur gewünschten BusyBox eintragen und dann dieses Verzeichnis in der PATH-Variablen beim Aufruf (einfach PATH="<my_dir>:$PATH" vor allem anderen in die Zeile schreiben) angeben - dann sollte exakt diese BusyBox gefunden werden beim "command -v busybox" und der Rest funktioniert dann wieder von alleine. Das gilt selbst dann, wenn das eine Box ist, für die passende Binaries in "modfs" vorliegen ... dann verwendet man einfach das passende VR9- oder GRX5-Verzeichnis unterhalb von "bin" in der PATH-Variablen (https://github.com/PeterPawn/modfs/tree/master/bin).

Das "run_modscripts" testet zwar noch einige Punkte, anstatt nur blind Kommandos aufzurufen, aber es war ja auch (s.o.) wieder nur als ein "Beispiel" gedacht. Wenn mir jemand die Zeilen liefert (es sind nur wenige, aber eine schöne Übung), mit denen eine vorhandene HWRevision-Variable direkt genutzt wird (wenn sie unterhalb von "bin" zu finden ist) und ansonsten das gefundene BusyBox-Binary (mit "--list" aufrufen für die Liste der enthaltenen Applets) erst mal auf das Vorhandensein der entscheidenden Applets abgeklopft wird (welche verwendet werden in den "modscripts", ist auch nicht schwierig zu ermitteln, ggf. sogar automatisch), übernehme ich das gerne auch noch in die "run_modscripts". Nur sind das eben "Randfälle" (mal von der Frage des Beispiels vollkommen abgesehen) und da fehlt mir tatsächlich der Antrieb - außerdem gibt es genug anderes zu tun.

 

[eisbaerin]

ist es am einfachsten, man packt gleich das gesamte AVM-Image mittels tar aus auf der Box und ersetzt dann nur noch die AVM-Dateien durch die eigenen

So ähnlich habe ich es mit einer FW 7.21 für die 7590 gemacht:
Originale FW ausgepackt, filesystem.image mit Prüfsumme ersetzt, eingepackt

Mit dieser Datei klappt:
mit tar auf der FB auspacken und mit /var/install installieren

Was nicht klappt:
mit dieser Datei in der FW 7.12 unter freetz ein Update machen
Es kommt der Fehler:
7590-07.21.mod is not a valid image file.

Woran liegt das? Was mache ich falsch?
IMO soll freetz jede FW ohne Signaturprüfung nehmen.

 

[PeterPawn]

 55 if [ "${FILENAME##*.}" != "image" ]; then
 56         "<h1>$(lang de:"Update vorbereiten" en:"Prepare update")</h1>"
 57         pre_begin
 58         echo "$FILENAME is not a valid image file."
 59         pre_end
 60         status "failed"
 61         do_exit 1
 62 fi

 

[eisbaerin]

Danke!
Aber schon komisch, oder?
IMO kann ich bei einer ganz normalen Installation über die AVM GUI die Datei benennen wie ich will.
Oder liege ich da falsch?

 

[PeterPawn]

Irgendjemand wird sich ja etwas gedacht haben, als er bei Freetz (wohl schon vor sehr langer Zeit) diese Prüfung eingebaut hat - vielleicht wurden zu oft irgendwelche ZIP-Dateien "angeboten" von den Benutzern.
EDIT: Das ist jetzt schon 9 Jahre so: https://github.com/Freetz/freetz/co...3a3687d34526a907f92f83e62da7e4e9365c35cd3fR55

Ich weiß es nicht und ich war es nicht ... ich hätte das auch anders gelöst.

Und ja ... das AVM-GUI interessiert sich nicht für den Dateinamen ... da wird die Datei aber auch direkt durch einen Filter gejagt, der überprüft, daß es sich (a) um ein TAR-File handelt und diese (b) keine "verbotenen" Dateinamen enthält - das wird dann gleich an ein "tar -x" verfüttert und damit existiert diese Image-Datei "als Ganzes" in einer AVM-Firmware beim Update überhaupt nicht. Stattdessen werden die Dateien alle sofort nach "/var/unpack" entpackt - hinterher wird dann entschieden, ob alles koscher ist mit der Image-Datei und wenn das so war, wird der Inhalt von "/var/unpack" nach "/" geschafft ... da hat es dann auch wieder die richtigen Namen (denn beim Entpacken landet die "/var/install" aus dem TAR-File eben in "/var/unpack/var/install").

Das handhabt Freetz vollkommen anders (zu finden in: make/mod/files/root/usr/lib/mww/do_update_handler.sh im Checkout bzw. - ab ".../root" - auch im Freetz-Image) - die Datei wird erst mal lokal gespeichert und es fehlen eben sämtliche weiteren Gültigkeitsprüfungen ... da wird blind entpackt, was in dem File steht (man verläßt sich halt darauf, daß es ein erlaubter Zugriff sein MUSS, wenn jemand eine Datei hochladen kann - die Tatsache, daß man auch Freetz ohne Shell-Zugriff bzw. mit deutlich besser gesicherter Shell, als es der "httpd" für das Freetz-GUI leistet, verwenden könnte, interessiert ohnehin nicht) und danach wird nur geschaut, ob da eine "/var/install" drin war und die wird dann aufgerufen. Stehen da irgendwelche Dateien für "/var/media/ftp" mit in der Image-Datei, werden die auch entpackt und überschreiben im schlechtesten Falle irgendwelche eigenen Dateien ... allerdings kann man dieses Wissen auch nutzen, um Dateien in die FRITZ!Box "einzuschleusen", ohne auf irgendwelche File-Services (von FTP über SFTP bis Samba) zugreifen zu müssen.

Aber das ist alles sooo steinalt an dieser Stelle und hat schon lange nichts mehr mit der Wirklichkeit bei AVM zu tun, daß es sich auch nicht im Ansatz lohnt, sich da noch irgendwelche Gedanken zu machen. An dieser Stelle ist Freetz immer noch auf dem Stand von Anno Knack, als auch AVM noch die "/var/post_install" löschte und beim Update eine vollkommen neue schrieb. Das ist lange vorbei ... heutzutage wird die fortgeschrieben, weil da der größte Teil zum "sauberen Beenden" der AVM-Dienste enthalten ist und AVM es wohl irgendwann auch keine sooo gute Idee mehr fand, das einfach alles "abzuwürgen".

 

[fda89]

Als die Boxen noch 8MB flash hatten, war es üblich external zu nutzen. Beim "make" kam dann eine .image und eine .external raus.
Die knifflige Aufgabe des Bedieners war dann, die .image über Firmwareupdate-Seite hochzuladen, und die .external über die external-Seite.
Das hat manchmal funktioniert.
Für den Rest gab es die Überprüfung

 

[eisbaerin]

Ich habe nur 20h gegrübelt wo der Fehler ist.
Für mich ist die Fehlermeldung irreführend.
Ich habe alles in der Datei vermutet und habe noch mal alles geprüft.
Vermutet hatte ich die Prüfsumme der filesystem.image,
dann das einpacken. Was sollte es denn sonst noch sein?

Wenn die Fehlermeldung eindeutig wäre:
This file must be end with .image
Dann hätte ich nicht mal 2s überlegen müssen.

 

[NDiIPP]

Wenn die Fehlermeldung eindeutig wäre:
This file must be end with .image
Dann hätte ich nicht mal 2s überlegen müssen.

Dann wären aber (früher) die Leute evtl. auf die dumme Idee gekommen, die *.external in *.image umzubenennen anstatt "einfach" die richtige zu verwenden.

 

[eisbaerin]

Hallo Peter, hat sich erledigt.

 

[PeterPawn]

Ich schaue es mir mal an, was da anders sein könnte. Dauert aber etwas ... ich tippe jedoch wieder mal auf "delay" und dessen Abhängigkeit vom gestarteten (und durchlaufenden) "multid".

Das verwende ich ja eigentlich nur, damit auch Fehler der Benutzer beim Inhalt der "rc.user" keine (folgenreichen) Auswirkungen auf den Rest der Firmware haben. Mal sehen, ob es nicht stattdessen mit "nohup" o.ä. besser funktioniert, eine eigene Prozessgruppe für die Abarbeitung der "rc.user" zu erzeugen - das dann aber wieder nur mit den Applets, die auch bei AVM in der BusyBox zu finden sind.

Es ist also - wenn man's von "delay" und "multid" unabhängig machen will - auch nichts, was man "einfach mal so" abändern kann/sollte. Der direkte Aufruf der "rc.user", aus dem "Service" heraus, verbietet sich (in meinen Augen) jedenfalls, weil dann mit dem Start irgendwelcher Schleifen oder irgendwelcher (dauerhaft laufender) Programme, die sich nicht richtig vom "parent" unabhängig machen, entweder die Abarbeitung wieder "gestoppt" wird oder gestartete Programme beim Ende des Skripts gleich wieder abgeräumt werden.

Das dafür prädestinierte "start-stop-daemon" (mit dem man einfach eine eigene Shell-Instanz für die "rc.user" starten könnte) ist bei AVM leider nicht in der BusyBox enthalten - deshalb MUSS man da ja überhaupt erst nach anderen Lösungen suchen (und auch ein "crond" ist bei AVM nicht dabei, über den man das ansonsten auch starten könnte). Alles andere, was AVM sonst noch so als "hooks" anbietet (bis hin zu den "onlinechanged"-Skripten), ist von anderen, zusätzlichen Faktoren abhängig, die nicht überall erfüllt sein müssen.

 

[eisbaerin]

Ich schaue es mir mal an

Danke! Hat sich aber erledigt.

Was mir noch positiv an der 7.2x FW aufgefallen ist:
Wenn ich z.B.mit tar oder unsqueshfs etwas nach /var/tmp/ entpacke und der Platz reichte nicht, dann ist eine 7.12 gnadenlos abgestürzt.
Bei den 7.2x passiert das nicht mehr und man erhält eine Meldung, daß kein Platz mehr vorhanden ist (natürlich auf englisch).

Noch eine Frage:
Mir ist bei der 7.21@7580 aufgefallen, daß nach dem Einspielen einer Sicherung die Daten im Online-Zähler wieder da sind.
Weißt du ab welcher FW das so ist?
IMO war da früher alles leer.

EDIT:
Peter, ich nehme alles zurück.
Nach einem erneuten reboot geht jetzt alles.

Warum ging es aber nicht nach dem 1. reboot?

 

[eisbaerin]

7580:$(pwd)# tar -x -f FRITZ.Box_7530-07.21.image
7580:$(pwd)# tar -x -f FRITZ.Box_7520-07.21.image
tar: short read
7580:$(pwd)#

Beim entpacken der originalen Dateien bekomme ich bei der 7520 obigen Fehler.
Bei der 7530 geht es ordentlich.
Ich habe die Datei auch nochmals von unterschiedlichen Quellen runter geladen, aber der Fehler bleibt.

Hat AVM da was falsch gemacht?
Oder woran liegt das?

 

[fda89]

Ich glaub das kann durch die angehängte Signatur auftreten

 

[eisbaerin]

Aber warum so unterschiedlich zwischen den fast gleichen Dateien?

Ich kann das also ignorieren?

 

[PeterPawn]

Ich kann das also ignorieren?

Kannst Du.

Das ist wohl wieder mal genau der 20. Fall beim Signieren ... bei den anderen 19 von 20 behandelt AVM das selbst richtig und es kommt ein (standardkonformes) TAR-File heraus beim Signieren.

Hier dürfte es so sein, daß die Datei eben nicht mit 1024 Byte aus Nullen beendet wird:

At the end of the archive file there are two 512-byte blocks filled with binary zeros as an end-of-file marker. A reasonable system should write such end-of-file marker at the end of an archive, but must not assume that such a block exists when reading an archive.

GNU tar 1.35: Basic Tar Format

GNU tar 1.35: Basic Tar Format

www.gnu.org

... und dann mault das "tar"-Kommando halt herum (je nach BusyBox-Version auch mal mit Exit-Code 1), wobei die AVM-Komponenten das intern dann ignorieren, wenn sie die Datei selbst verarbeiten.

EDIT:
Exakt so ist es auch:

peh@vidar:~> wget -qO- https://ftp.avm.de/fritzbox/fritzbox-7520/deutschland/fritz.os/FRITZ.Box_7520-07.21.image | hexdump -C | tail -n 10
01d4e410  b8 85 9f 46 ce 6a 01 93  0f a0 07 6a f9 ac cc 41  |...F.j.....j...A|
01d4e420  f7 9f 67 e4 6d 3e de b8  b9 dc 5f 4f b7 14 d2 6c  |..g.m>...._O...l|
01d4e430  da d8 2d b1 02 6d 8f 28  68 5d 47 1d e6 f7 cc 80  |..-..m.(h]G.....|
01d4e440  ec 50 bc f9 f9 50 c4 48  ea bd c5 8a de 97 f0 ef  |.P...P.H........|
01d4e450  7f 45 a0 82 36 07 fa f2  64 0a d5 a3 e5 64 45 f1  |.E..6...d....dE.|
01d4e460  20 cd d7 4d c3 c6 2a d0  14 8f ee 9c 26 16 01 b3  | ..M..*.....&...|
01d4e470  1a ed d5 fa f0 ca 59 3b  f5 df 0d 70 7f 1a be f9  |......Y;...p....|
01d4e480  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d4e800
peh@vidar:~>

- eigentlich müßte die Datei 0x1d4ea00 (30730752) Byte groß sein, weil die beiden leeren 512-Byte-Blöcke an 0x1d4e600 und 0x1d4e800 beginnen müßten. Von 0x1d4e480 bis 0x1d4e600 sind es zwar auch Nullen, die sind aber das Auffüllen der "/var/signature" (Dateigröße 128 Byte) auf die 512 Byte der Blockgröße im TAR-Archiv.

 

[eisbaerin]

PeterPawn schrieb:
Kannst Du.

Danke, dann bin ich ja beruhigt.

----------------------

Das ist wohl wieder mal genau der 20. Fall beim Signieren ... bei den anderen 19 von 20 behandelt AVM das selbst richtig

Das sind aber doch mehr. Ich habe nur mal bei der 7.21 geschaut:
FRITZ.Box_6850_LTE-07.21-82312-LabBETA.image
FRITZ.Box_6660_Cable-07.21.image

 

[fda89]

Das soll heissen dass die Wahrscheinlichkeit bei 0,05 liegt

 

[eisbaerin]

0,05

???
Bei mir waren es jetzt 3 von 12. Das sind 25% oder 0,25.

 

[fda89]

Da fällt mir wirklich nichts dazu ein