[Problem] post_install Skript nicht ausführbar

[maceis]

Hallo zusammen,

ich habe gestern für eine 6590 eine neue Firmware gebaut.
Auf der Box ist bereits Freetz drauf.
Beim Versuch, die neue FW über das Firmware-Update in Freetz hochzuladen, erhalte ich am Ende die Meldung.
"Fehler: Nach-Installationsskript nicht gefunden oder nicht ausführbar."

Das post_install Skript ist unter /var/post_install vorhanden, aber nicht ausführbar.
Die Suche im Forum hat mich zu verschiedenen (teilweise sehr alten) Threads geführt, die mir aber alle nicht wirklich geholfen haben.
Was kann ich tun, um die FW auf die Box zu bekommen?
Falls weitere Informationen benötigt werden, bitte Bescheid geben, was Ihr braucht.

Der Inhalt des post_install Skript ist:

#! /bin/sh
echo $0: start
sleep 1
killall run_clock
if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
if ps | grep -v grep | grep -q telnetd ; then killall telnetd ; fi
echo skip deleting language from env
echo MODE=update > /dev/avm_power
echo "disable" > /dev/watchdog
echo init-start 20 >/dev/watchdog
echo still running:
ps
lsmod
sleep 1
echo clear_id 93 >/proc/tffs
echo clear_id 94 >/proc/tffs
echo clear_id 95 >/proc/tffs
echo clear_id 96 >/proc/tffs

Die Ausgabe unterhalten b von "Ausführen des Firmware-Installationsskripts /var/install ..." ist.

install: have Kernel 2.6.39.3 - set kversion '2.6.39' and FlashUpdateTool '/lib/modules/2.6.39.3/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=
ANNEX=Kabel
testing acceptance for device Fritz_Box_HW220a ...
korrekt install type: arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac4x4_kabel_31385
device has installtype arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac4x4_kabel_31385
assumed ANNEX Kabel -- found ANNEX Kabel
device has ANNEX Kabel
OK - accept this update for device Fritz_Box_HW220a ...
testing acceptance for device Fritz_Box_HW220a done
curr: 148.06.87  new: xx.06.87
debug: curr: 148.06.87
debug: new: "XX.06.87"
major_currFWver=148
middle_currFWver=6
minor_currFWver=87
middle_newFWver=6
minor_newFWver=87
check Firmware Version: xx.06.87
DEBUG: 6 >= 6
DEBUG: 87 >= 87
Accept Firmware Version: xx.06.87
install: 2.6.39 check files...
read 0xac03d78d MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xac03d78d
Calculated checksum is AC03D78D
Saved checksum is AC03D78D
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/filesystem.image ok
size for file /var/remote/var/tmp/x86/filesystem.image ok
read 0x904542c0 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x904542c0
Calculated checksum is 904542C0
Saved checksum is 904542C0
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/kernel.image ok
size for file /var/remote/var/tmp/x86/kernel.image ok
read 0xde85973f MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xde85973f
Calculated checksum is DE85973F
Saved checksum is DE85973F
Checksum validation successful!
chksum for file /var/remote/var/tmp/filesystem.image ok
size for file /var/remote/var/tmp/filesystem.image ok
read 0xccb34c8d MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xccb34c8d
Calculated checksum is CCB34C8D
Saved checksum is CCB34C8D
Checksum validation successful!
chksum for file /var/remote/var/tmp/kernel.image ok
size for file /var/remote/var/tmp/kernel.image ok
817+1 records in
818+0 records out
6309+1 records in
6310+0 records out
452+1 records in
453+0 records out
1392+1 records in
1393+0 records out

 

[PeterPawn]

Was kann ich tun, um die FW auf die Box zu bekommen?

Sie über den Bootloader oder (dann natürlich signiert) über das AVM-GUI installieren - fertig.

Wenn man den Inhalt der "/var/post_install" oben mit dem originalen Inhalt vergleicht (das Original kann man aus der "/var.tar" extrahieren), fällt einem ja auf, daß die vorhandene Datei nur noch die Zeilen enthält, die direkt aus der "/var/install" geschrieben werden. Ursache ist schlicht diese Zeile: https://github.com/Freetz/freetz/bl...es/root/usr/lib/mww/do_update_handler.sh#L170 - das AVM-Skript für die Installation versucht jedenfalls, die vorhandene "/var/post_install" fortzuschreiben:

# next: prepare_update
#! /bin/sh
##################################################################################
# prepare install
##################################################################################
# do no longer overwrite/remove /var/post_install
if [ ! -f /var/post_install ] ; then
# create, if not present
  echo "#! /bin/sh" >/var/post_install
fi
# append sequence to /var/post_install
echo 'echo $0: start' >>/var/post_install
# LED- und Betriebsstundenzaehler- Demon stoppen
echo "sleep 1" >>/var/post_install
echo "killall run_clock" >>/var/post_install
echo "if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi" >>/var/post_install
echo "if ps | grep -v grep | grep -q telnetd ; then killall telnetd ; fi" >>/var/post_install

Ich predige seit langem, daß der Installationsprozess in Freetz NICHT zu dem abweichenden Vorgehen in der "/var/install" von AVM paßt, was für die Puma6-Modelle verwendet wird - das geht bei der falschen "Ansage" los, daß die Installation erst beim Neustart ausgeführt würde, obwohl sie längst erfolgt ist und endet eigentlich auch bei dieser Aktion in Zeile 170 oben noch nicht.

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

Die möglichen Ursachen für das abweichende Verhalten der "/var/post_install" bei Dir in Freetz sind jedenfalls vielschichtig, wobei es hier wohl schlicht auf einen Benutzerfehler hinauslaufen wird, wenn die "/var/post_install" nicht ausführbar ist. Wobei man - je nach Sichtweise - auch dem Freetz-Mod dafür die Schuld geben könnte, denn beim Fortschreiben einer vorhandenen Datei werden deren Attribute ja nicht geändert und für das Löschen zeichnet ja der Freetz-Mod verantwortlich.

Ursächlich dürfte jedenfalls auch der "falsche" Wert für "umask" sein - denn unter dem AVM-System wird "0022" verwendet und eine damit erzeugte Datei ist automatisch immer ausführbar. Wenn die neu geschriebene Datei bei Dir unter Freetz keine x-Flags gesetzt hat, wird da offenbar eine andere Maske verwendet, die wohl irgendwie auf "0133" (o.ä.) hinauslaufen wird, wenn ich raten sollte.

Ob die jetzt generell gesetzt ist oder ob die jemand in irgendeiner eigenen "profile"-Datei selbst eingestellt hat, sollte jeder Freetz-Benutzer (der auch den "mod" verwendet) selbst ermitteln können - ich finde beim "grep" in "make/mod" jedenfalls keine Stelle, wo Freetz selbst die "umask" dauerhaft verstellen würde, also liegt die Vermutung nahe, daß das irgendwo in der Installation des Freetz-Users liegt. Das könnte zwar auch eine generelle Freetz-Einstellung sein (ich verwende den "mod" ja nie), aber ich wüßte dann nicht, wo ich noch suchen sollte.

EDIT: Da fällt mir doch noch ein, wo man parallel mal nachsehen müßte ... die Abarbeitung der ganzen "handler"-Skripte in Freetz erfolgt ja aus dem CGI-Aufruf heraus - denkbar, daß da doch noch (dann in "make/modcgi") irgendwo eine eigene "umask" gesetzt wird und es gar keine "benutzerdefinierte" gibt, die für das Problem verantwortlich ist. Aber auch das ist "nicht mein Tisch" ... ich schaue da also nicht nach. Ich wüßte nicht, warum die Installation über das AVM-GUI nicht funktionieren sollte, wenn man seine Images signiert und diese Funktion ist seit langem in Freetz vorhanden - also einfach das benutzen, was auch funktioniert (s.u.). Punkt.

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

Am Ende kommen hier wohl mehrere Probleme zusammen und solange sich niemand eingehend mit der Überarbeitung des Installationsprozesses befaßt hat, sollte man eben die Wege benutzen, die bekanntermaßen auch funktionieren. Wer unbedingt das Freetz-GUI benutzen will, der muß es eben "reparieren" und das geht am Ende bis zum Setzen der passenden "umask" an der Stelle, wo von Freetz die "/var/install" von AVM dann aufgerufen wird ... jedenfalls dann, wenn das einigermaßen "fail-safe" sein soll. Dann paßt zwar Text und Vorgehen des Freetz-GUI für die Puma6-Boxen immer noch nicht, aber es kommt nicht mehr zu diesem Fehler.

 

[maceis]

Danke für deine Antwort.


Signieren hat bei mir leider noch nie funktioniert.
Zum Bauen verwende ich Seite und je freetz-linox mit umask 0022
Das endet dann mit der Ausgabe:
Generating random seed file from /dev/random (may take some time) ... FAILED
Mit 'cat /dev/random' kommen jede Menge Zufallszeichen raus; weiter bin ich da nicht gekommen.

Über den Bootoader würde wohl gehen, aber ich wollt mir das eigentlich ersparen.
Den Installationsprozess zu überarbeiten übersteigt leider meine Kenntnisse.

 

[PeterPawn]

Zum Bauen verwende ich Seite und je freetz-linox mit umask 0202

Verstehe ich nicht ...

Signieren hat bei mir leider noch nie funktioniert.

Dann sollte man da mal schauen, wo es tatsächlich klemmt.

Denn an dem Kommando an dieser Stelle:

https://github.com/PeterPawn/YourFritz/blob/master/signimage/generate_signing_key#L198

kann eigentlich nicht so sehr viel schiefgehen ... außer es stimmen auch hier irgendwelche Rechte (für "/dev/random" oder die "Zieldatei") nicht.

Meines Wissens kann "/dev/random" die Blockzugriffe (die durch "dd" erfolgen, auch wenn "/dev/random" eigentlich ein Character-Device ist - zumindest funktioniert es ja bei anderen auch) und 256 Byte "Zufall" mit ausreichender Entropie (also 2048 Bit) sollten bei einem einigermaßen lange laufenden System mit ein paar Console-Eingaben und etwas Harddisk-Bewegung auch zur Verfügung stehen, erst recht, wenn Daemons wie "haveged" laufen, was heutzutage auf praktisch jedem modernen Linux-System der Fall sein dürfte.

Ansonsten bleibt ja auch immer noch die Möglichkeit (habe ich im Header der Datei bzw. bei der Erklärung der Skript-Dateien hier im IPPF beschrieben), das Seed-File einfach selbst anzulegen und zuvor bereits mit passenden Daten zu befüllen ... dann greift Zeile 196 (bzw. sie greift eben nicht) und es kommt gar nicht erst zum Versuch, die Datei selbst zu erstellen.

Wobei mich schon mal interessieren würde, was an einem Kommando dd if=/dev/random of="$HOME/.freetz.image_signing.rnd" bs=16 count=16 eigentlich schiefgehen sollte ... außer daß eben doch keine Daten kommen und die (Ziel-)Datei daher doch nicht existiert - wobei die ja wenigsten als leeres File existieren müßte (da mache ich tatsächlich noch einen falschen Test, weil die leere Datei gar nichts bringt ... korrigiere ich bei Gelegenheit).

Wenn's wirklich an den Blockzugriffen scheitert (was ist das für ein Linux als Build-Host?), kann man das ja auch als cat /dev/random | dd of="$HOME/.freetz.image_signing.rnd" bs=16 count=16 aufrufen, hier greift dann das cat mit char-Orientierung zu und das dd dient nur noch zum Zählen der Bytes und zum Abbruch, wenn's reicht. Und nochmal ... das Seed-File wird nur ein einziges Mal angelegt - ebenso wird ja der zu verwendende Key nur ein einziges Mal erzeugt.

Wer das also von Hand macht (mit dem oben verlinkten "generate_signing_key") und die Dateien dann selbst an die richtige Stelle legt, bei dem wird "fwmod" auch das Generieren des Keys nicht mehr aufrufen. Wer stets mit einem neuen Build-Host arbeitet, der muß den Key ohnehin sichern und immer wieder einspielen ... denn wenn er beim nächsten Build (der dann auch den Build-Host umfaßt) wieder einen neuen Key generiert, nutzt der auch nichts mehr zum Signieren eines akzeptablen Pakets für die alte Freetz-Version, die sich bereits auf der Box befindet.

 

[maceis]

Hallo Peter,

das mit der umask war ein Tippfehler, Sorry.
Ich meinte natürlich 0022 (hab's oben geändert).
Den Rest Deiner Antwort muss ich erstmal durcharbeiten.

Wenn ich das mit dem Signieren richtig verstanden habe, müsste ich aber zuerst mal einen Weg (z. B. Bootloader)finden, die erste signierte FW auf die Box zu bringen, richtig?

Edit: Build Host ist ein freetz-linox (eine Ubuntu Variante, die mal speziell zum Bauen von Freetz verteilt wurde).

--

Mit dem Kommando dd if=/dev/random of="$HOME/.freetz.image_signing.rnd" bs=16 count=16 konnte ich die Datei $HOME/.freetz.image_signing.rnd erstellen.

Mit make erhalte ich jetzt folgendes Ergebnis:

cat build/modified/sign_image.log
Found OpenSSL 1.0.1 14 Mar 2012
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
Input file doesn't look like a TAR archive.

Ich weiß nicht, was hier mit input file gemeint ist, das image im Ordner "images" ist jedenfalls ein TAR Archiv

In meinem $HOME liegen danach folgende Dateien

ls -la $HOME/.freetz.*         
-rw-r--r-- 1 freetz freetz 266 Jul 28 19:02 /home/freetz/.freetz.image_signing.asc
-rw-r--r-- 1 freetz freetz 986 Jul 28 19:02 /home/freetz/.freetz.image_signing.key
-rw-r--r-- 1 freetz freetz 272 Jul 28 19:02 /home/freetz/.freetz.image_signing.pem
-rw-r--r-- 1 freetz freetz 256 Jul 28 19:01 /home/freetz/.freetz.image_signing.rnd

Mir ist noch was komisches aufgefallen:
Meine letze FW, die ich im April gebaut hatte, hat folgenden Dateinamen:
6590_06.87-freetz-master-a2d4950-.de_20190428-161555.image.
Das jetzt gebaute Image heißt:
6590_06.87-freetz-unknown.de_20190728-190209.image.unsigned

Kann das etwas mit meinem Problem zu tun haben?

 

[PeterPawn]

Wenn das ein "freetz-linux" auf Ubuntu-Basis (vor allem auf einer aktuellen, also mind. Ubuntu 16) ist, stellt sich die Frage, warum das Generieren des Keys nicht funktionieren sollte ... das machen andere Freetz-Benutzer ja auch auf diesem Weg und auch das Signieren von Images funktioniert meines Wissens bei anderen. Ansonsten hätte ich sicherlich schon entsprechende Beschwerden gelesen ... auch wenn ich das nicht selbst teste, weil ich eben keine Freetz-Images verwende.

Wie gesagt ... die Merkwürdigkeiten gehen hier ja schon bei der Generierung des Keys los (warum sollte das per manueller Eingabe funktionieren, aber nicht, wenn es von "fwmod" aufgerufen wird) und auch die Frage, was da jetzt dem Skript zum Signieren als Datei wohl angeboten wird, kann ich aus der Ferne nicht beantworten. Ein passendes TAR-File sollte jedenfalls ab Offset 257 die Zeichenfolge "ustar" in seinem Header haben (https://www.gnu.org/software/tar/manual/tar.html#SEC187) und wenn es das nicht hat, ist wohl das verwendete "tar"-Kommando "etwas komisch" (auch wenn das natürlich dann wieder seine eigenen Dateien lesen kann und der Meinung sein mag, das wäre ein korrekter Aufbau).

Wobei in Freetz ohnehin das "tar"-Applet der BusyBox verwendet werden sollte (müßte) und das erzeugt eigentlich korrekte TAR-Header ... nur macht es diese Feststellung halt nicht weniger mysteriös, was da bei Dir schiefgehen mag.

Ob die ausgecheckte Version (aus der auch der Image-Name abgeleitet wird, der Dir komisch erscheint) am Ende damit etwas zu tun hat, weiß ich nicht ... aber ich frage einfach noch einmal um der Sicherheit willen: Du benutzt aber schon den Master oder einen Fork des "genuine Freetz", oder? Bei Freetz-NG bin ich jedenfalls raus ... da wurde - gerade bei diesem Thema - so viel umgeworfen, daß ich mich da definitiv nicht "einarbeiten" werde.