[Gelöst] push_firmare "latest.image" (Freetz-NG) vs. /sbin/burnuimg "firmware-update.uimg" (ffritz)

[jha4711]

UPDATE 3: !!! Lösung gefunden (siehe Post#16) !!! - Lösungsweg bis dahin in diversen Posts davor!

UPDATE 2: So einfach scheint es doch nicht - siehe Post #2 - Thema wieder von "Gelöst" auf "Frage" zurückgestellt.

UPDATE 1: "Kann man denn bitte so blöd sein ???"

Die Lösung ist ja soooo simple - "tar xf 6591_07.29.ger_freetz-ng-20017-cb46fac03_20220707-080755.image" auf der Box und dann wie üblich mit "/sbin/burnuimg /var/media/ftp/var/firmware-update.uimg || echo FAILED" flashen sowie mit "/bin/aicmd pumaglued uimg switchandreboot" die Bootbank wechseln und booten

Bitte erzählt es nicht weiter - Danke

Gelöst ....

Hallo zusammen,

seit gestern mache ich erste "Gehversuche" mit Freetz-NG und konnte bereits erfolgreich ein Freetz-NG Image (symbolic link "latest.image" auf das erzeugte 7590_07_39.....image) erzeugen und über tools/push_firmware auf eine 7590 flashen.

Soweit so gut ... jetzt wollte ich auch mal ein Freetz-NG Image für eine 6591 ausprobieren.

Habe mir also ein 6591_07.29.ger_freetz-ng-20017-cb46fac03_20220707-080755.image erzeugt und "könnte" das über den Bootloader (also tools/push_firmare) sicherlich genauso aufspielen ...

ABER ich würde es gerne über die "scp" und "ssh" Methode machen, mit denen ich bisher die 6591 gepatched habe, also ohne den EVA-Bootloader dafür zu "bemühen".

Sprich:
1. image erzeugen und per scp auf die Box spielen
2. per ssh auf der Box anmelden und das image flashen (analog zum "/sbin/burnuimg /var/media/ftp/var/firmware-update.uimg")

Da ich auf meiner Bastlerbox ja nichts kaputt machen kann, habe ich das einfach mal probiert und bin "natürlich auf die Schnauze gefolgen"

# /sbin/burnuimg /var/media/ftp/6591_07.29.ger_freetz-ng-20017-cb46fac03_20220707-080755.image || echo FAILED
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg update
burnuimg: <<< 227 /usr/sbin/avm_uimg_update starting.
avm_uimg_update: Failed.
UIMG: exit 1
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg status
burnuimg: <<< 225 update status follow.
STATUS exit 1
burnuimg: exit(exit code indicated failure)
FAILED

Jetzt die Frage, mit der ich mich natürlich als jemand oute, der die Grundlagen - sprich den Unterschied zwischen einem Freetz-NG Image und diesem bisher von mir verwendeten "uimg" - nicht wirklich verstanden hat bzw. verstehen will.

Was ich gesehen habe ist, dass es beim "tools/push_firmware" einen Switch "-mu" für "uimg" Methode gibt. Aber auch hier scheint der Bootloader zum flashen eine Rolle zu spielen.

Usage: tools/push_firmware [image] [ -m<s|r|d|u|f> ] [ -f ] [ -w ] [ -ip <ip> ] [ -map <hex> ] [ -ali <kb> ] [ -ram <mb> ] [ -lfs <0|1|9> ] [ -cmd <ftp|ncftp> ]
...
[image]           When no 'image' file is given, images/latest.image will be tried.
...
-mu               Force mode uimg-boot (newer docsis devices, like 6591 & 6660)
                    See https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md
...

Würde mich freuen, wenn mir jemand ...
a) ... mit wenigen, leicht verständlichen Worten den Unterschied zwischen diesem "uimg" und dem "image" erklären könnte. Beides enthält ja die eigentliche Firmware, aber bei der ffritz Version u.a. als TAR-File mit zusätzlichen "Metadaten"
b) ... einen Befehl nehmen könnte, mit dem ich auch ohne Bootloader - also in einer "ssh Session" - ein Freetz-NG image direkt flashen könnte - falls das überhaupt geht.

Mir fehlt als reiner "Anwender" wohl offensichtlich das Verständnis bzgl. des konkreten Unterschieds "Freetz-NG" und "ffritz"

Danke euch

 

[jha4711]

Ok, so blöd war die ursprüngliche Frage wohl doch nicht, denn bei installiertem Freetz-NG image klappen die vom ffritz bekannten Tools auf meiner 6591 nicht mehr. Sie sind von einer vorigen Installation zwar noch vorhanden, aber so einfach ist es dann unter der gebooteten Freetz-NG doch nicht!

Soll heißen - ich brauch dann ggf. doch noch eure Hilfe. Also doch eine Antwort auf die ursprünglich gestellte Frage, wenn man vorher nicht mit ffritz gearbeitet hat. Konkreter Fehler unter Freetz-NG:

/bin/aicmd pumaglued uimg switchandreboot
aicmd: <<< 425 switch aid failed (-1).
sh: getcwd: No such file or directory

Mein persönlicher Workaround: Über die Freetz-NG GUI die Bootbank Switches (dann bin ich ja wieder auf der ursprünglichen ffritz Umgebung. Diese Booten und darüber dann die neueste Freetz-NG einspielen

Ok, bis ich eine coolere Lösung habe (bin gerade am Kämpfen mit dem Firmware-Update über die Freetz-NG GUI, der nicht so recht klappen will), werde ich so wohl damit umgehen müssen

 

[PeterPawn]

AVM hat die Installation bei den Puma7-Geräten irgendwann geändert ... und ob das inzwischen überhaupt wieder klappt, aus Freetz(-NG) oder auch aus dem AVM-GUI heraus eine modifizierte Firmware zu installieren, ist (meines Wissens jedenfalls) nicht bis zum Ende untersucht: https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/post-2451175

Aber offenbar ist das ja ein anderer Fehler (verglichen mit dem verlinkten Thread), der da bei Dir auftritt - allerdings ist das bei Dir auch nur ein kleiner Ausschnitt aus den verfügbaren Logs, wobei deren Vorhandensein und der Umfang dann auch davon abhängt, was man am Ende wie installieren will.

Irgendwie wird man aber aus dem bisher Beschriebenen auch nicht so richtig schlau ... ich sehe nicht, daß Dein burnuimg irgendwie ERFOLGREICH war und dennoch willst Du mittels aicmd auf das andere System wechseln? Je nachdem, wo das Schreiben der neuen Daten abgebrochen wurde, steht da gar kein gültiges System in den Partitionen.

Haben denn die von Dir bisher verwendetenn Kommandos (ohne Freetz-NG) schon mal bei einer FRITZ!OS-Version funktioniert, die bereits mit dem NEUEN Verfahren bei der Installation arbeitet (also dem Aufruf von avm_uimg_update auf dem ARM-Core als Ergebnis eines burnuimg-Aufrufs auf dem ATOM-Core)?

Die Installation eines Updates über das Freetz-NG-GUI KANN eigentlich nicht funktionieren, da bei den Puma7-Boxen der Installationsvorgang eben NICHT nur über die Ausführung von /var/install und /var/post_install erledigt wird (so macht das die Modifikation in Freetz(-NG) aber: https://github.com/Freetz-NG/freetz...d/files/root/usr/lib/mww/do_update_handler.sh) - der Aufruf von burnuimg, den das AVM-Programm für ein GUI-Update (firmwarecfg) nach dem Abarbeiten der /var/install ausführt (siehe hier: https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/post-2451117), findet beim Updateversuch über das Freetz-Interface gar nicht erst statt (zumindest finde ich keinen).

Bleibt also noch der Updateversuch über das AVM-GUI - dazu muß das eigene Image signiert sein und der passende Key in der laufenden FRITZ!OS-Instanz installiert sein. Die Frage, ob es dann an einer falschen Signatur scheitert, sollte in dem bereits verlinkten Thread ausreichend geklärt sein ... es scheitert(e) dort nicht an der Signatur, sondern an einem Problem beim Aufruf (aus firmwarecfg heraus) von avm_uimg_update auf dem ARM-Core. Das scheint hier bei Dir nicht mehr der Fall zu sein, wobei das

burnuimg: <<< 227 /usr/sbin/avm_uimg_update starting.
avm_uimg_update: Failed.

aus #1 auch nicht dafür spricht (selbst wenn das "von Hand" von Dir aufgerufen wurde), daß da die Installation erfolgreich gewesen wäre. WELCHES Problem konkret im avm_uimg_update auftrat, kann man irgendwie nicht so richtig erkennen - da MUSS es irgendwo noch eine genauere Protokollierung geben bzw. da wäre es schon nützlich, wenn Du es mal mit einem Update per signiertem Image über das AVM-GUI probierst (dann sieht man wenigstens etwas in der Protokolldatei, die dabei von firmwarecfg nach /var/tmp geschrieben wird).

Jedenfalls solange Du nicht WIRKLICH sicher bist, das auch bei einer FRITZ!OS-Version mit dem "neuen Updateverfahren" (und die Nachricht "uimg: using new update functionality" - im anderen Thread per grep bzw. strings gefunden im entsprechenden Binary auf dem ARM-Core - gibt es sicherlich auch nicht wirklich umsonst) bereits erfolgreich "von Hand" gemacht zu haben mit einem Aufruf von burnuimg -das Kommando gibt/gab es eben auch schon in älteren Versionen, nur arbeitete da das Gesamtkonstrukt noch anders (das hat @fesc dann in dem anderen Thread ja auch festgestellt).

 

[jha4711]

AVM hat die Installation bei den Puma7-Geräten irgendwann geändert ... und ob das inzwischen überhaupt wieder klappt, aus Freetz(-NG) oder auch aus dem AVM-GUI heraus eine modifizierte Firmware zu installieren, ist (meines Wissens jedenfalls) nicht bis zum Ende untersucht: https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/post-2451175

... na dann hab ich mir ja genau das richtige Thema zum "Rumspielen" gesucht

Irgendwie wird man aber aus dem bisher Beschriebenen auch nicht so richtig schlau ... ich sehe nicht, daß Dein burnuimg irgendwie ERFOLGREICH war und dennoch willst Du mittels aicmd auf das andere System wechseln? Je nachdem, wo das Schreiben der neuen Daten abgebrochen wurde, steht da gar kein gültiges System in den Partitionen.

... das tut mir leid. burnuimg klappt bei mir schon immer, allerdings nur, wenn ich die ffritz firmware laufen habe. Das war ich eben auch gewohnt und dachte "naiv", damit kann ich dann ja auch bei laufender Freetz-NG Firmware ein neues Image flashen.

Haben denn die von Dir bisher verwendetenn Kommandos (ohne Freetz-NG) schon mal bei einer FRITZ!OS-Version funktioniert, die bereits mit dem NEUEN Verfahren bei der Installation arbeitet (also dem Aufruf von avm_uimg_update auf dem ARM-Core als Ergebnis eines burnuimg-Aufrufs auf dem ATOM-Core)?

... Ja - siehe oben - ich verwende diese Methode regelmässig und quasi problemlos auf meinen beiden 6591 Bastlerboxen sobald eine neue Laborversion verfügbar ist. "Same procedure as every year" .... erst das ffritz-Repo aktualisieren, dann in der conf.mk die URL anpassen...make...scp image auf die 6591 ... burnuimg ... switchandreboot .... voila. Ist normalerweise ne Sache von nicht mal 5 Min. wenn alles gut geht. Seit vorgestern, als ich die coole GUI von Freetz-NG erstmals auf einer 7590 gesehen habe, hatte ich halt das Bedürfnis, mal eben auch auf die 6591 aufzuspielen.

Die Installation eines Updates über das Freetz-NG-GUI KANN eigentlich nicht funktionieren, da bei den Puma7-Boxen der Installationsvorgang eben NICHT nur über die Ausführung von /var/install und /var/post_install erledigt wird (so macht das die Modifikation in Freetz(-NG) aber: https://github.com/Freetz-NG/freetz...d/files/root/usr/lib/mww/do_update_handler.sh) - der Aufruf von burnuimg, den das AVM-Programm für ein GUI-Update (firmwarecfg) nach dem Abarbeiten der /var/install ausführt (siehe hier: https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/post-2451117), findet beim Updateversuch über das Freetz-Interface gar nicht erst statt (zumindest finde ich keinen).

... als ich dann "irgendwann" den Menüpunkt "Firmware Update" im Freetz-NG gefunden hatte und die "burnuimg" Methode in einer ssh-shell nicht funktioniert hatte, habe ich das halt über die Freetz-NG probiert und von dort den Output des /var/install hier in meinen Post gepasted.

Bleibt also noch der Updateversuch über das AVM-GUI - dazu muß das eigene Image signiert sein und der passende Key in der laufenden FRITZ!OS-Instanz installiert sein. Die Frage, ob es dann an einer falschen Signatur scheitert, sollte in dem bereits verlinkten Thread ausreichend geklärt sein ... es scheitert(e) dort nicht an der Signatur, sondern an einem Problem beim Aufruf (aus firmwarecfg heraus) von avm_uimg_update auf dem ARM-Core. Das scheint hier bei Dir nicht mehr der Fall zu sein, wobei das

burnuimg: <<< 227 /usr/sbin/avm_uimg_update starting.
avm_uimg_update: Failed.

aus #1 auch nicht dafür spricht (selbst wenn das "von Hand" von Dir aufgerufen wurde), daß da die Installation erfolgreich gewesen wäre. WELCHES Problem konkret im avm_uimg_update auftrat, kann man irgendwie nicht so richtig erkennen - da MUSS es irgendwo noch eine genauere Protokollierung geben bzw. da wäre es schon nützlich, wenn Du es mal mit einem Update per signiertem Image über das AVM-GUI probierst (dann sieht man wenigstens etwas in der Protokolldatei, die dabei von firmwarecfg nach /var/tmp geschrieben wird).

... ok, danke für diesen Hinweis. Hab ich gemacht. Output ist:

root@fritzbox6591-2:/var/tmp# cat /var/tmp/fwupdate.log
16:52:26 firmwarecfg(14609): starting firmware update via command 'UploadFile'
16:52:26 firmwarecfg(14611): delayed reboot helper process waiting for pid 14609 to terminate
16:52:37 firmwarecfg(14609): get_file with max_size=732954624
16:52:41 firmwarecfg(14609): waiting for the tar process to terminate
16:52:41 firmwarecfg(14609): tar process terminated
16:52:41 firmwarecfg(14609): signature ok
16:52:41 firmwarecfg(14609): prepare_firmware_upgrade returns g_status=0
16:52:41 firmwarecfg(14609): now_install
16:52:43 firmwarecfg(14609): calling /var/install
16:52:43 firmwarecfg(14609): waiting for /var/install to complete
16:52:43 firmwarecfg(14621): Running /var/install
16:52:43 firmwarecfg(14609): /var/install exited normally with status=1
16:52:43 firmwarecfg(14609): /var/install returned  g_status=1
16:52:43 firmwarecfg(14609): burnuimg starting ...
16:52:44 firmwarecfg(14609): ERROR burnuimg exit 20
16:52:44 firmwarecfg(14609): ERROR burnimage_uimg failed
16:52:44 firmwarecfg(14609): killing delayed reboot helper process 14611

Fehlermeldung in der avm-GUI dann

Jedenfalls solange Du nicht WIRKLICH sicher bist, das auch bei einer FRITZ!OS-Version mit dem "neuen Updateverfahren" (und die Nachricht "uimg: using new update functionality" - im anderen Thread per grep bzw. strings gefunden im entsprechenden Binary auf dem ARM-Core - gibt es sicherlich auch nicht wirklich umsonst) bereits erfolgreich "von Hand" gemacht zu haben mit einem Aufruf von burnuimg -das Kommando gibt/gab es eben auch schon in älteren Versionen, nur arbeitete da das Gesamtkonstrukt noch anders (das hat @fesc dann in dem anderen Thread ja auch festgestellt).

... hier weiß ich jetzt nicht, wie ich das nachprüfen / belegen kann. Die Zeichenkette "uimg: using new update functionality" habe ich jedenfalls auf meinem Buildhost in den von mir verwendeten Quellen (vom ffritz Repository) gefunden.

~/development/6591/bitbucket/ffritz$ strings build/puma7/arm/orig/sbin/pumaglued  | grep "uimg\|sector"
uimg: using new update functionality
uimg: REBOOT now
Invalid sector "%s".
uimg: %s starting ...
/usr/sbin/avm_uimg_update
uimg: %s started.
uimg: update finished - %s%s
uimg: switch aid failed (%d)
uimg: switched, rebooting ...
uimg

Das würde also erklären, warum das burnuimg bei mir funktioniert, wenn ein ffritz image läuft und ich müsste wirklich "nur" noch rausfinden, wie ich ein image unter laufendem Freetz-NG aktualisieren / flashen kann.

Ansonsten läuft es halt darauf hinaus, bei einem Update erst mal wieder ffritz zu booten und dann ein aktuelles Freetz-NG zu flashen. Habe ich heute mehrere Male probiert - klappt definitiv. Und vielleicht gibt es ja irgendwann einmal auch einen Freez-NG Update, nach dem dann das Flashen der Firmware auch auf einer 6591 über die GUI (oder die avm-GUI) klappt.

In jedem Fall VIELEN DANK mal wieder für Deine wertvollen Hinweise. Der Exkurs war mal wieder extrem interessant.

 

[PeterPawn]

Bleibt also die Frage übrig, was sich hinter:

16:52:43 firmwarecfg(14609): burnuimg starting ...
16:52:44 firmwarecfg(14609): ERROR burnuimg exit 20
16:52:44 firmwarecfg(14609): ERROR burnimage_uimg failed

verbergen mag.

Solange sich dazu auf dem ARM-Core keine näheren Informationen finden lassen (das Protokoll stammt ja vom ATOM-Core und zeigt am Ende nur das "Ergebnis" dessen, was auf dem ARM-Core passierte), solltest Du vielleicht erst einmal versuchen zu ergründen, ob das Problem an den Daten (also am verwendeten Image) oder an der Umgebung (also am laufenden FRITZ!OS, mit oder ohne Modifikationen) liegt.

Das dürfte sich am einfachsten feststellen lassen, wenn man mal aus einem laufenden Freetz-Image heraus ein (dateibasiertes) Update über das AVM-GUI mit einem originalen AVM-Image versucht (solange die Versionsnummer paßt, sollte das machbar sein). Wenn das auch nicht funktioniert, liegt es vermutlich an der "Umgebung" (und dann weiß man zumindest, wo man mit weiteren Nachforschungen ansetzen sollte) und wenn das aber klappen sollte, dann gibt es offenbar doch noch Unterschiede zwischen dem originalen uimg-Format von AVM und dem, was von dem Utility von @fesc erzeugt wird (vielleicht wirkt sich das ja auch erst in den neueren FRITZ!OS-Versionen aus und war bei früheren Versionen noch kein Thema).

 

[fesc]

Kommen denn keine konsolenen-ausgaben am atom?
Das schreiben der mmc partitionen findet auf dem arm statt (das sieht man wenn man bei einem laufendem burnuimg):

# ps | grep avm_uimg_update
 9938 root     12420 S    avm_uimg_update 1
 9949 root      2180 S    grep avm_uimg_update
# ls -l /proc/9938/fd
lrwx------    1 root     root            64 Jul  9 15:19 0 -> socket:[868099]
lrwx------    1 root     root            64 Jul  9 15:19 1 -> socket:[868099]
lrwx------    1 root     root            64 Jul  9 15:19 2 -> socket:[868099]
lrwx------    1 root     root            64 Jul  9 15:19 3 -> /dev/mmcblk0p3

Vorher sollte aber das aid (active image directory) ausgelesen werden um festzustellen auf welche partitionen geschrieben werden muss. Das wiederum passiert auf dem atom ueber einen rpc call (rpc_mgm_aid_get_1_svc), welcher vom rpc_management_server behandelt wird indem dieser aid_config_utility aufruft. Das AID ist im SPI flash gespeichert, dort wird für jede mmc partition hinterlegt welches die aktive ist.

Wer jetzt genau diesen rpc call macht weiss ich nicht, aber auf jeden fall sollte man ihn am atom auf der konsole sehen:

# setconsole -r
# setconsole $tty
# /sbin/burnuimg var/firmware-update.uimg
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg update
Debug: rpc_mgm_aid_get_1_svc Finish running the command to get the active image indexDebug: rpc_mgm_aid_get_1_svc Start running the command to get the active image index
[DEBUG]: main:194:active image partition[0] = 1
...
burnuimg: <<< 227 /usr/sbin/avm_uimg_update starting.
avm_uimg_update: OK

Ich kann mir irgendwie nicht vorstellen warum das eigentliche schreiben auf die mmc partitionen schiefgehen sollte, und auch das uimg file scheint ja korrekt zu sein (sonst würde es auf einem nicht-freetz ja nicht gehen). Vielleicht stimmt auf freetz etwas mit dem rpc service nicht? Das müssste man ja an den debug-ausgaben sehen.

Dazu würde auch dieser fehler passen, welcher wohl über den rpc_mgm_aid_set call läuft.

/bin/aicmd pumaglued uimg switchandreboot
aicmd: <<< 425 switch aid failed (-1).
sh: getcwd: No such file or directory

Sieht man denn ob avm_uimg_update was auf die mmc partitionen schreibt (ls -l /proc/XXX/fd immer wieder ausführen)?

 

[jha4711]

@fesc und @PeterPawn : Wow - so wie ich mich gerade fühle, nachdem ich eure Texte gelesen habe, muss sich Catweazle gefühlt haben, als er den Telefonhörer gefunden hat . Aber was heule ich rum - ich wollte das "Spiel" schließlich spielen. Werde also versuchen eure Ratschläge und Vorschläge zu be- und zu verfolgen ... aber das dauert bestimmt ein wenig.

Was ich aber jetzt schon sagen kann ist, dass das flashen eines Original avm Images (Release UND Labor) über die avm GUI bei laufenden Freetz-NG heraus auch nicht geklappt hat.

Je nach "Versuchsaufbau" (habe verschiedene Versuche, z.B. laufendes Freetz-NG image aus Laborversion oder Releaseversion - weil Downgrades in der avm GUI ja nicht zu funktionieren scheinen) kam da mal ...

tail -f /var/tmp/fwupdate.log
11:10:31 firmwarecfg(12827): starting firmware update via command 'UploadFile'
11:10:31 firmwarecfg(12829): delayed reboot helper process waiting for pid 12827 to terminate
11:10:43 firmwarecfg(12827): get_file with max_size=732954624
11:10:46 firmwarecfg(12827): waiting for the tar process to terminate
11:10:46 firmwarecfg(12827): tar process terminated
11:10:46 firmwarecfg(12827): signature ok
11:10:46 firmwarecfg(12827): prepare_firmware_upgrade returns g_status=0
11:10:46 firmwarecfg(12827): now_install
11:10:48 firmwarecfg(12827): calling /var/install
11:10:48 firmwarecfg(12827): waiting for /var/install to complete
11:10:48 firmwarecfg(12849): Running /var/install
11:10:48 firmwarecfg(12827): /var/install exited normally with status=1
11:10:48 firmwarecfg(12827): /var/install returned g_status=1
11:10:48 firmwarecfg(12827): burnuimg starting ...
11:10:48 firmwarecfg(12827): ERROR burnuimg exit 20
11:10:48 firmwarecfg(12827): ERROR burnimage_uimg failed
11:10:48 firmwarecfg(12827): killing delayed reboot helper process 12829

oder auch mal ein

tail -f /var/tmp/fwupdate.log
11:22:01 firmwarecfg(10334): starting firmware update via command 'UploadFile'
11:22:01 firmwarecfg(10336): delayed reboot helper process waiting for pid 10334 to terminate
11:22:14 firmwarecfg(10334): get_file with max_size=732954624
11:22:17 firmwarecfg(10334): waiting for the tar process to terminate
11:22:17 firmwarecfg(10334): tar process terminated
11:22:17 firmwarecfg(10334): signature ok
11:22:17 firmwarecfg(10334): prepare_firmware_upgrade returns g_status=0
11:22:17 firmwarecfg(10334): now_install
11:22:19 firmwarecfg(10334): calling /var/install
11:22:19 firmwarecfg(10334): waiting for /var/install to complete
11:22:19 firmwarecfg(10368): Running /var/install
11:22:19 firmwarecfg(10334): /var/install exited normally with status=8
11:22:19 firmwarecfg(10334): /var/install returned g_status=8
11:22:19 firmwarecfg(10334): killing delayed reboot helper process 10336

Details muss ich aber bei erneuten Versuchen noch einmal zusammentragen und da kommt die Hilfestellung von @fesc natürlich gerade zur rechten Zeit. Also - bis die Tage ... und Danke nochmal.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Ich kann mir irgendwie nicht vorstellen warum das eigentliche schreiben auf die mmc partitionen schiefgehen sollte, und auch das uimg file scheint ja korrekt zu sein (sonst würde es auf einem nicht-freetz ja nicht gehen). Vielleicht

Mit laufendem Freetz-NG (Firmware: 161.07.29 rev92035, Freetz: ng-20043-b14d90966) und einem Original AVM Image (firmware-update.uimg stammt aus einem Original fb6591_7.29-31.tar) bin ich jetzt bei diesem "Invalid sector -1" Fehler, der auch in dem von @PeterPawn weiter oben verlinkten Thread (Post#27) besprochen wurde.

/sbin/burnuimg /var/media/ftp/var/firmware-update.uimg
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg update
burnuimg: <<< 500 Invalid sector "-1".
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg status
burnuimg: <<< 225 update status follow.
NONE

Auf der anderen Bootbank (linux_fs_start=0) müsste eigentlich ein ffritz liegen, das definitiv funktioniert hatte, weil ich von dort mit einem "switch_bootbank" eben in das Freetz-NG (linux_fs_start=1) gebootet hatte.

Aber wenn ich jetzt über den Bootloader / EVA linux_fs_start=0 setze und REBOOTe, hängt die Box und die Power/Cable LED blinkt schnell.

Erst ein Power-Reset erweckt sie wieder zum Leben und sie bootet "zurück" ins Freetz-NG.

Wenn ich das richtig interpretiere, dann hat der Befehl /sbin/burnuimg /var/media/ftp/var/firmware-update.uimg mit Fehler "Invalid sector -1" von oben, das ursprünglich funktionierende ffritz doch zerschossen - oder übersehe ich da etwas. (z.B. weil die Box ja eine alte Providerbox ist und ein Original 7.29 avm image dort "natürlich" nicht booten könnte, falls der Befehl eben doch etwas geflashed hat?)

Werde als nächstes per Bootloader das ffritz erneut flashen (um wieder den Zustand 1 x Freetz-NG und 1 x FFRITZ auf den Bootbanks zu haben) und melde mich dann wieder.

 

[fesc]

burnuimg: <<< 500 Invalid sector "-1".

Das Symptom sehe ich wenn ich rpcbind neu starte. Dann kennt rpcbind die services von rpc_management_server nicht, und man muss diesen auch neu starten.
(edit: Ich glaube nicht dass dadurch was zerschossen wird).

Was läuft denn an rpc diensten? So sollte es aussehen:

# ps | grep rpc
4708 root 2756 S grep rpc
4882 root 0 SW [avmcsrpc]
7941 root 2792 S rpcbind -h 169.254.1.1
9202 root 2552 S rpc_management_server 169.254.1.1 169.254.1.2

(man beachte die Reihenfolge)

# kill 9202
# nohup rpc_management_server 169.254.1.1 169.254.1.2&

Und den update nochmal probieren.

 

[jha4711]

Was läuft denn an rpc diensten? So sollte es aussehen:

der rpc_management_server läuft nicht ...

ps | grep rpc
2028 root 2792 S rpcbind -h 169.254.1.1
9656 root 1648 S grep rpc

... und lässt sich auch nicht starten ...

nohup rpc_management_server 169.254.1.1 169.254.1.2&
nohup: appending output to nohup.out

[1]+ Done(1) nohup rpc_management_server 169.254.1.1 169.254.1.2

/var/media/ftp# cat nohup.out
Cannot register service: RPC: Unable to receive; errno = Connection refused
unable to register (RPC_MGM_PROG, RPC_MGM_VERSION, tcp).
Server IP addr 169.254.1.1
Client IP addr 169.254.1.2
RPC management server bind successfully to 169.254.1.1

Update: habe einfach mal ein grep über die Files in /var/tmp gemacht .... sollte die vielen "no such device or address" etwa zu denken geben ??? ...

/var/tmp# grep -i rpc *
grep: avmnexus_CtlmgrTimerConfig.ctl: No such device or address
grep: avmnexus_MacList.ctl: No such device or address
grep: avmnexus_NetworkDevices.ctl: No such device or address
grep: avmnexus_UpdateCheck.ctl: No such device or address
grep: avmnexus_WLANConfigSlave.ctl: No such device or address
grep: avmnexus_WLANStationExchangeSlave.ctl: No such device or address
grep: avmnexus_aha::ep:ldapi.ctl: No such device or address
grep: avmnexusd.ctl: No such device or address
grep: avmnexusd_cfg.ctl: No such device or address
grep: boxnotify: No such device or address
grep: foncontrol: No such device or address
grep: homeauto: No such device or address
grep: me_AHAKPIReceiver.ctl: No such device or address
grep: me_DECTKPIReceiver.ctl: No such device or address
grep: me_KPI.ctl: No such device or address
grep: me_SATIP.ctl: No such device or address
grep: me_TR064.ctl: No such device or address
grep: me_TR069_AVM_CLIENT.ctl: No such device or address
grep: me_WLAN_LIB_NEXUS.ctl: No such device or address
grep: me__anony2820-136349873.ctl: No such device or address
grep: me__anony2820-3255012664.ctl: No such device or address
grep: me__anony4824-2352126343.ctl: No such device or address
grep: me_atom_pucd.ctl: No such device or address
grep: me_avm_home_external.ctl: No such device or address
grep: me_avmdebug.ctl: No such device or address
grep: me_avmipc_state.ctl: No such device or address
grep: me_avmipcd.ctl: No such device or address
grep: me_avmnexusd.ctl: No such device or address
grep: me_cableinfo.ctl: No such device or address
grep: me_cloudmsgd-pcp-3719.ctl: No such device or address
grep: me_cloudmsgd-pcp-4879.ctl: No such device or address
grep: me_ctlmgr-pcp-2800.ctl: No such device or address
grep: me_ctlmgr.ctl: No such device or address
grep: me_ctlmgrtimer.ctl: No such device or address
grep: me_ddnsd.ctl: No such device or address
grep: me_deviceinfod.ctl: No such device or address
grep: me_dhcpv6info.ctl: No such device or address
grep: me_dsld-pcp-3680.ctl: No such device or address
grep: me_dsld.ctl: No such device or address
grep: me_dvbif.ctl: No such device or address
grep: me_extswitch_watch.ctl: No such device or address
grep: me_igd.ctl: No such device or address
grep: me_igd2.ctl: No such device or address
grep: me_kpi_name_receiver.ctl: No such device or address
grep: me_kpid.ctl: No such device or address
grep: me_l2tpv3d.ctl: No such device or address
grep: me_logic.ctl: No such device or address
grep: me_meshconfig_client_regevent.ctl: No such device or address
grep: me_meshd.ctl: No such device or address
grep: me_multid-pcp-3250.ctl: No such device or address
grep: me_multid.ctl: No such device or address
grep: me_pcpd-pcp-3633.ctl: No such device or address
grep: me_pcpd.ctl: No such device or address
grep: me_pumaupdatetrace.ctl: No such device or address
grep: me_remote.ctl: No such device or address
grep: me_systemKPIReceiver.ctl: No such device or address
grep: me_tfa_dtmf.ctl: No such device or address
grep: me_tr064srv.ctl: No such device or address
grep: me_upnpd.ctl: No such device or address
grep: me_upnpd_stream.ctl: No such device or address
grep: me_upnpfboxdesc.ctl: No such device or address
grep: me_usbinfod.ctl: No such device or address
grep: me_voipd.ctl: No such device or address
grep: me_vpnd.ctl: No such device or address
grep: notifyd_msg: No such device or address
grep: pb_event: No such device or address
grep: pbctrl: No such device or address
grep: pbmsg: No such device or address
grep: sec_pm_daemon_socket: No such device or address
grep: supervisor.ctrl.socket: No such device or address
grep: supervisor.notify.socket: No such device or address
grep: tamlua: No such device or address
grep: tel_ipc: No such device or address
grep: telefon_aha_socket: No such device or address
grep: wlancsi_async.socket: No such device or address
grep: wlancsi_listener_10e273ecc880721d2cd14b.socket: No such device or address
grep: wlancsi_listener_b046.
ec62a404ec71133d.socket: No such device or address

Ich tendiere dazu, mal einen Werksreset zu versuchen, dann wieder ein ffritz und ein Freetz-NG image zu flashen und noch einmal alles von vorne zu testen. Warte aber erst mal (den Sonntag ) ab, ob zu diesem Post noch Reaktionen kommen.

 

[HarryHase]

kein leerzeichen zwishen rpc und * , grep -i rpc*

 

[jha4711]

kein leerzeichen zwishen rpc und * , grep -i rpc*

??? Ich wollte in allen Files "*" (im aktuellen Verzeichnis /var/tmp) die Zeichenkette "rpc" suchen, unabhängig von Groß-Kleinschreibung "-i" und bekomme zwar keine Ergebnisse (also "rpc" scheint in keinem der Files vorzukommen), dafür bekomme ich den Hinweis, dass sehr viele Files (siehe Liste) gar nicht wirklich existieren. Darauf wollte ich eigentlich nur hinweisen.

Verstehe Deine Frage daher nicht, denn ein "grep -i rpc*" (ohne Space zwischen rpc und * macht doch gar keinen Sinn bzw. ließt von stdin wenn ich mich nicht irre)

Edit: Hätte ich - was eigentlich meine Intuition war - nur in den Logfiles gesucht, wäre das mit den "No such device oder address" gar nicht aufgefallen - hätte aber auch nichts gefunden ...

root@fritzbox6591-2:/var/tmp# grep -i rpc *.log
root@fritzbox6591-2:/var/tmp#

 

[PeterPawn]

Das sind alles Sockets, die da "nicht gefunden" werden - mit denen kann grep nicht umgehen (und außerdem haben die keinen "Inhalt" im herkömmlichen Sinn).

 

[fesc]

Zumindest erklärt das warum der firmware update nicht funktioniert.
Ich habe jetzt keine Erfahrung mit rpc und warum da ein connection refused kommen könnte. Der rpc_management_server versucht sich halt bei rpcbind zu registrieren, und irgend eine Eigenheit in freetz verhindert das. Wird denn rpcbind neu gebaut/ersetzt?
Was sagt denn "rpcinfo"? Vielleicht sieht man da was besonderes. So sollte es aussehen (das letzte wäre dann wohl rpc_management_server):

# rpcinfo
program version netid address service owner
100000 4 tcp6 ::1.0.111 - superuser
100000 3 tcp6 ::1.0.111 - superuser
100000 4 udp6 ::1.0.111 - superuser
100000 3 udp6 ::1.0.111 - superuser
100000 4 tcp 169.254.1.1.0.111 - superuser
100000 3 tcp 169.254.1.1.0.111 - superuser
100000 2 tcp 169.254.1.1.0.111 - superuser
100000 4 udp 169.254.1.1.0.111 - superuser
100000 3 udp 169.254.1.1.0.111 - superuser
100000 2 udp 169.254.1.1.0.111 - superuser
100000 4 local /var/run/rpcbind.sock - superuser
100000 3 local /var/run/rpcbind.sock - superuser
572660088 1 tcp 0.0.0.0.173.185 - superuser

 

[jha4711]

Was sagt denn "rpcinfo"?

rpcinfo sagt ...

root@fritzbox6591-2:/var/mod/root# rpcinfo
program version netid address service owner
100000 4 local /var/run/rpcbind.sock - superuser
100000 3 local /var/run/rpcbind.sock - superuser
root@fritzbox6591-2:/var/mod/root#

... also deutlich weniger als in Deinem Output.

Ich werde also mal versuchen, das ffritz wieder zum Laufen zu bringen und darunter das rpcinfo auszuführen. Muss es aber erst mal über den Bootloader neu flashen, denn aktuell kann ich die Bootbank ja nicht mehr wechseln - warum auch immer? .... und dann prüfe ich das rpcinfo noch einmal und gebe Bescheid.

Um es noch mal explizit zu fragen: Beim Erstellen "meiner" ffritz-images habe ich ja diesen "user_oem.patch" extra verwendet, das kann ich ja beim Freetz-NG nicht (oder ich weiss nicht, wie das ginge). Kann diese ganze "Problematik" vielleicht einfach "nur" daran liegen? Sprich: beim ffritz patche ich ja die Provider-Box explizit mit diesem Patch, beim Freetz-NG wird - so wie ich das verstehe - so ein Patch aber nicht angewendet.

Edit: ... und früher ist so eine Box ohne user_oem.patch ja gar nicht hochgefahren. Mittlerweile scheint die avm-Firmware da aber nicht mehr so restriktiv zu sein, zumindest ist doch irgendwann einmal aufgefallen, dass Providerboxen auch ohne Patch hochfahren (es fehlt halt "nur" der ssh-Zugriff und andere nette Dinge), wenn ich mich nicht täusche.

 

[fesc]

Das heisst das rpcbind nicht auf port 111 lauscht. Das ist der standard rpc port, mit dem auch rpc_management_server versucht sich zu verbinden. Kann also nicht gehen.
Hast du mal versucht rpcbind zu killen und neu zu starten?

Ich kann mir nicht vorstellen was der patch damit zu tun hat. Der soll ja nur bewirken dass die Box überhaupt bootet.


Edit: Ich habe mir mal ein freetz image gebaut. Was mir auffällt dass da ziemlich viele Änderungen in /etc/services sind. u.A.

Original:

sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP

freetz:

sunrpc 111/tcp
sunrpc 111/udp

Ich habe das mal in meiner lokalen buildroot umgebung getestet, wenn ich rpcbind so starte dann öffnet er, wie bei Dir, keinen port 111. Er braucht also den portmapper alias.

--> freetz fixen!
--> make/mod/files/root/etc/services editieren, portmapper alias eintragen, neu bauen

 

[jha4711]

--> make/mod/files/root/etc/services editieren, portmapper alias eintragen, neu bauen

Habe ich gemacht und siehe da ......

Welcome at fritzbox6591-2
Linux fritzbox6591-2 4.9.250 #1 SMP PREEMPT 2021-07-15 i686 GNU/Linux

_____ _ _ _ ____
| ___| __ ___ ___| |_ ____ | \ | |/ ___|
| |_ | '__/ _ \/ _ \ __|_ /____| \| | | _
| _|| | | __/ __/ |_ / /_____| |\ | |_| |
|_| |_| \___|\___|\__/___| |_| \_|\____|


BusyBox v1.34.1 (2022-07-09 15:51:16 CEST) built-in shell (ash)

root@fritzbox6591-2:/var/mod/root# rpcinfo
program version netid address service owner
100000 4 tcp 169.254.1.1.0.111 - superuser
100000 3 tcp 169.254.1.1.0.111 - superuser
100000 2 tcp 169.254.1.1.0.111 - superuser
100000 4 udp 169.254.1.1.0.111 - superuser
100000 3 udp 169.254.1.1.0.111 - superuser
100000 2 udp 169.254.1.1.0.111 - superuser
100000 4 local /var/run/rpcbind.sock - superuser
100000 3 local /var/run/rpcbind.sock - superuser
572660088 1 tcp 0.0.0.0.192.155 - superuser

... ein switch_bootbank Befehl "/bin/aicmd pumaglued uimg switchandreboot" unter meinem "neuen" Freetz-NG hat auch geklappt ...

Edit: Ich glaube fast - DAS WAR's - will aber den Tag nicht vor dem Abend loben und werde natürlich noch das eigentliche Problem von GANZ VORNE - "Wie kann ich unter Freetz-NG ein neues Image flashen" verfolgen und sobald ich da auch Erfolg habe lass ich es euch wissen ...

!!! burnuimg bei laufendem Freetz-NG klappt auch !!! DANKE !!!

cd /var/media/ftp/
root@fritzbox6591-2:/var/media/ftp# /sbin/burnuimg var/firmware-update.uimg
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg update
burnuimg: <<< 227 /usr/sbin/avm_uimg_update starting.
avm_uimg_update: OK
APPCPU Kernel: type 2, size 9437184
APPCPU RootFS: type 3, size 35024896
NPCPU Kernel: type 8, size 2697984
NPCPU RootFS: type 9, size 16318464
GWFS: type 10, size 30720
UIMG: exit 0
burnuimg: <<< 220 pumaglued ready.
burnuimg: >>> uimg status
burnuimg: <<< 225 update status follow.
STATUS exit 0

... (und zahle @fesc ein Bier )

 

[fesc]

Ich habe mal einen freetz-ng pull-request gemacht (https://github.com/Freetz-NG/freetz-ng/pull/586). Aber eigentlich ist mmn. das ganze services-file "im Eimer", deshalb auch gleich ein issue (https://github.com/Freetz-NG/freetz-ng/issues/587).

 

[PeterPawn]

Mit nunmehr funktionierenden RPC-Services und nach den jüngsten Änderungen am Update-Skript von Freetz-NG (https://github.com/Freetz-NG/freetz-ng/commit/b14d90966c4f86f44722ec598c993aa5fff9929f), sollte dann ja auch das Update aus Freetz-NG heraus bei den Puma7-Modellen insgesamt funktionieren. Entweder über das Freetz-NG-GUI (da geht es dann auch ohne Signatur, weil das Update-Image NICHT weiter geprüft wird) oder über das AVM-GUI (wie bei anderen Modellen auch), wobei dafür ein eigener Key im laufenden System vorhanden sein und das zu flashende Image passend signiert sein muß.

Ich linke mal noch von dem älteren Thread (https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/post-2451175) auf diesen hier, damit spätere Leser es einfacher haben, eine Lösung zu finden bzw. zu erfahren, seit wann und weshalb das jetzt (wieder) funktioniert.

 

[jha4711]

damit spätere Leser es einfacher haben

... In diesem Zusammenhang auch noch der Hinweis auf folgenden Post bzw. den gesamten Thread, der den fehlenden Menu-Punkt "System->Firmware-Update" im Freetz-NG bei Puma Boxen behandelt.

Darüber bin ich auch gestolpert und habe - weil ich Freetz-NG bis jetzt ja gar nicht kannte - an mir gezweifelt, weil ich in der Freezt-NG GUI NIRGENDS die Möglichkeit gefunden hatte, die Firmware zu aktualisieren.

Begründung: Es kann vorkommen, dass bei Puma Boxen (z.B. 6591) der GUI Menupunkt "Firmware-Update" deaktiviert bzw. nicht erstellt wird. Ein Update kann man dann aber immer noch über die avm GUI anstoßen (oder eben wie hier im Thread beschrieben über ssh und entsprechende Befehle s.o.)

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

sollte dann ja auch das Update aus Freetz-NG heraus bei den Puma7-Modellen insgesamt funktionieren. Entweder über das Freetz-NG-GUI (da geht es dann auch ohne Signatur, weil das Update-Image NICHT weiter geprüft wird) oder über das AVM-GUI (wie bei anderen Modellen auch), wobei dafür ein eigener Key im laufenden System vorhanden sein und das zu flashende Image passend signiert sein muß.

Kann ich heute morgen auch bestätigen ... Zumindest für den Firmware Update über die avm GUI kann ich den Beleg liefern ...

root@fritzbox6591-2:/var/tmp# tail -F fwupdate.log
07:56:31 firmwarecfg(29245): starting firmware update via command 'UploadFile'
07:56:31 firmwarecfg(29247): delayed reboot helper process waiting for pid 29245 to terminate
07:56:43 firmwarecfg(29245): get_file with max_size=732954624
07:56:56 firmwarecfg(29245): waiting for the tar process to terminate
07:56:56 firmwarecfg(29245): tar process terminated
07:56:56 firmwarecfg(29245): ERROR signature missing or wrong
07:56:56 firmwarecfg(29245): prepare_firmware_upgrade returns g_status=26
07:56:56 firmwarecfg(29245): killing delayed reboot helper process 29247
tail: fwupdate.log has been replaced; following end of new file
08:01:37 firmwarecfg(29387): starting firmware update via command 'UploadFile'
08:01:37 firmwarecfg(29389): delayed reboot helper process waiting for pid 29387 to terminate
08:01:49 firmwarecfg(29387): get_file with max_size=732954624
08:01:58 firmwarecfg(29387): waiting for the tar process to terminate
08:01:58 firmwarecfg(29387): tar process terminated
08:01:58 firmwarecfg(29387): signature ok
08:01:58 firmwarecfg(29387): prepare_firmware_upgrade returns g_status=0
08:01:58 firmwarecfg(29387): now_install
08:02:00 firmwarecfg(29387): calling /var/install
08:02:00 firmwarecfg(29387): waiting for /var/install to complete
08:02:00 firmwarecfg(29401): Running /var/install
08:02:01 firmwarecfg(29387): /var/install exited normally with status=1
08:02:01 firmwarecfg(29387): /var/install returned g_status=1
08:02:01 firmwarecfg(29387): burnuimg starting ...
08:02:23 firmwarecfg(29387): burnuimg complete
08:02:23 firmwarecfg(29387): **** REBOOT now because of INSTALL_SUCCESS_REBOOT ****
08:02:25 firmwarecfg(29387): switchandreboot
08:02:26 firmwarecfg(29387): puma7_switch_and_reboot ok
Connection to fbc2 closed by remote host.
Connection to fbc2 closed.

Der obere Teil mit dem Fehler zeigt den fwupdate.log mit einem Image, für das es noch keinen key auf dem laufenden System gab. Dann wurde ein image verwendet, für dass es einen key gab und "voila" Firmware-Update über die avm-GUI hat geklappt.

Über die Freetz-GUI gibt es (bei meinem image) keinen Menüpunkt für das firmware-update, aber das wurde im Post davor bereits erwähnt.

Ich denke, mit dieser finalen Bestätigung kann dieser Thread tatsächlich als "gelöst" betrachtet werden. Danke noch einmal und eine schöne Woche.

 

[prisrak1]

Mit /sbin/burnuimg /var/media/ftp/var/firmware-update.uimg || echo FAILED wird die passive Partition geflasht. Kannn mir jemand bitte einen Tipp geben, wie lauten die Befehle für:

aktiven Partitionsset (Variable "linux_fs_start") auslesen
gezieltes flächen auf eine von mir bestimmte Partition

in PowerShell sind mir die Befehle bekannt. Aber in Putti eben nicht.