Das Protokoll (Support-Daten) habe ich in #602 ergänzt.
Wenn es bereits beim Extrahieren des Kernels auftritt, wird es wohl die zweite vermutete Ursache sein und siehe da:
Code:
wget -qO- ftp://ftp.avm.de/fritz.box/fritzbox.5490/firmware/deutsch/FRITZ.Box_5490.de-en-es-it-fr-pl.151.06.51.image | tar tv
drwxr-xr-x 0/0 0 2016-01-28 15:11:08 ./var/
drwxr-xr-x 0/0 0 2016-01-28 15:11:08 ./var/tmp/
-rw-r--r-- 0/0 2507016 2016-01-28 15:11:08 ./var/tmp/kernel.image
-rw-r--r-- 0/0 21442568 2016-01-28 15:11:08 ./var/tmp/filesystem.image
-r-xr-x--- 0/0 283844 2015-10-20 16:19:38 ./var/regelex
-rwxr-xr-x 0/0 33395 2016-01-28 15:11:08 ./var/install
-rwxr-xr-x 0/0 2795 2016-01-28 15:11:08 ./var/info.txt
-r-xr-x--- 0/0 278552 2015-10-20 16:19:38 ./var/chksum
-rw-r--r-- 0/0 128 2016-01-28 15:11:08 ./var/signature
[COLOR="#FF0000"]tar: short read[/COLOR]
Welche Folgen das "short read" jetzt für den Exit-Code des tar-Applets (und in der Folge für die weitere Behandlung im Skript) hat, hängt u.a. von der Busybox-Version ab. Da die ab 0.3.4 eine definierte ist (die dort eben keinen Exit-Code > 0 erzeugt), klappt es mit der neuen Version dann ... was auch gleich noch eine schöne "Bestätigung" des Ansatzes mit der eigenen Busybox ist, dann war das eben doch nicht ganz umsonst.
@Shirocco88:
Die drei Fundstellen ändere ich noch, die anderen Kommandos wie "printf" und "expr" laufen bei mir unter dem "usw." in der Aufzählung der "shell builtins". Es war gar nicht beabsichtigt, die Aufrufe dieser Kommandos gegen das "Unterjubeln" von anderen Programmen zu härten (steht auch irgendwo in den commit-Kommentaren) - das ist bei der Busybox und der AVM-Firmware, wo eben für jedes denkbare Shell-Konstrukt (selbst für "test" bzw. "[" / "[[") auch ein Symlink existieren könnte, auch gar nicht so einfach, wie es auf den ersten Blick aussehen mag.
Im Gegensatz zu den anderen Kommandos ist (soweit ich weiß) aber keine unterschiedliche Arbeitsweise/Ausgabe bei diesen Kommandos zu erwarten (zumindest bei den von mir verwendeten Optionen, beim "read" gibt es wohl auch noch Sachen, die man "weglassen" kann beim Build) oder zum gegenwärtigen Zeitpunkt schon bekannt. Streng genommen wäre das nicht einmal beim "uname -r" der Fall, weil die Beschränkung der Ausgabe auf die Kernelversion eben Unterschiede in den anderen Teilen (verglichen mit "uname -a") uninteressant macht.
Nun gibt es (vermutlich, für "definitiv" müßte ich auch erst suchen) das bash-Builtin "enable" bei der "ash" eher nicht ... da die "ash" meines Wissens eine Mischung der (Builtin-)Kommandos der "Bourne shell" und der "Bourne-Again shell" bereithält (z.B. gibt es die bash-Spezialität "local" oder "alias" in der Busybox, woher die bash die jetzt haben mag (ob von der csh oder der ksh), ist ja egal in diesem Kontext), ist meine Absicht eigentlich die, syntaktisch eindeutige Kommandos aus der Builtin-Liste dieser beiden Shell-Dialekte (
https://www.gnu.org/software/bash/manual/bashref.html#Shell-Builtin-Commands) nicht unbedingt mit einem expliziten Pfad aufrufen zu müssen. Das geht zwar wahrscheinlich auch, aber es ist für die Funktion wohl eher unnötig.
Das mag an anderen Stellen (wo ich das trotzdem mache) auch so sein, da gilt dann aber wieder "vorbeugen ist besser als nach hinten fallen" und solange es
nur wenige "Fundstellen" sind, ist das auch noch vertretbar. Aber spätestens bei der Entscheidung "Builtin" oder "externes Kommando" wird es dann unangenehmer, ein Beispiel wäre hier "pwd", was von der Busybox durchaus unter beiden Aspekten verstanden wird, wenn ich mich richtig erinnere.
Ich würde da jetzt auch nicht päpstlicher als der Papst sein ... bei "uname" ist das noch eine Überlegung wert, auch wenn die GNU coreutils da wenig Spielraum für unterschiedliche Implementierungen lassen (
http://www.gnu.org/software/coreutils/manual/html_node/uname-invocation.html#uname-invocation), bei "sleep" wird es schon enger, weil das "genauere sleep" auf der Box eben "usleep" heißt (wenn es vorhanden ist) und bei "printf", "expr" und den restlichen Kommandos, die in aller Regel (von den meisten) nicht von "echten Shell-Schlüsselwörtern" (wie if, for, exit, usw.) unterschieden werden können, würde ich dann doch darauf verzichten, solange keine Gefahr besteht, daß ein anderes Verhalten (tar) bzw. eine andere Syntax beim Aufruf (blkid, mount, losetup) da zu Problemen führen kann.
Sollten sich also noch Stellen finden (über die bereits von Dir aufgezeigten "sleep"- und "uname"-Aufrufe hinaus), wo Kommandos betroffen sind, die nicht in der oben verlinkten Liste der "bash builtins" auftauchen (auch wenn die "ash" die nicht komplett umsetzt bzw. Teile davon dann schon wieder externe Kommandos sind), dann nehme ich die gerne noch ... aber die anderen Stellen halte ich persönlich für unnötig (wie gesagt, es geht nicht darum, das "Ersetzen" solcher Kommandos durch den Benutzer als "Angriff" zu unterbinden, siehe meine Anmerkung im git-Commit).
