[Frage] Update auf neue Version FB6591

Ajari

Neuer User
Mitglied seit
20 Aug 2007
Beiträge
16
Punkte für Reaktionen
0
Punkte
3
Hi,

ich hab jetzt schon einige male versucht ein Update für meine FB6591 zu flashen. Auf alles Seiten die ich gefunden habe steht das ich einfach nur das image über das Webinterface flashen kann. Allerdings geht das weder im "orginalem" Interface noch über das Update Menü im Freetz-NG Interface.
Beim Updaten über das Fritz-Box Interface werde ich auf die Seite http://fritz.box/cgi-bin/firmwarecfg weitergeleitet mit Folgendem Inhalt:
Code:
firmwarecfg: ERROR
Error: opening page ../html/tools/update_result_noreboot.html
Die Info LED blinkt, aber mehr passiert nicht.

Beim Updateversuch über das Freetz Interace steht zwar da es wäre erfolgreich, aber nach dem Reboot ist immernoch die alte Version drauf.
Code:
install: check and install new firmware ...
OEM=
ANNEX=Kabel
testing acceptance for device Fritz_Box_HW233a ...
korrekt install type: arm_4GB_xilinx_4eth_2ab_isdn_nt_usb3host_dect_wlan11ac4x4_kabel_31065
device has installtype arm_4GB_xilinx_4eth_2ab_isdn_nt_usb3host_dect_wlan11ac4x4_kabel_31065
OK - accept this update for device Fritz_Box_HW233a ...
testing acceptance for device Fritz_Box_HW233a done
curr: 161.07.29  new: xx.07.29
debug: curr: 161.07.29
debug: new: "XX.07.29"
major_currFWver=161
middle_currFWver=7
minor_currFWver=29
middle_newFWver=7
minor_newFWver=29
check Firmware Version: xx.07.29
DEBUG: 7 >= 7
DEBUG: 29 >= 29
Accept Firmware Version: xx.07.29
sh: 24: unknown operand

Im Anhang die .config
 

Anhänge

  • config.txt
    89.5 KB · Aufrufe: 4
Stimmt, mit push-firmware geht's, ist für mich aber immer recht umständlich. Ich habe nicht die Standart IP Range, die FB hängt hinter nem Switch, hab nicht nur eine Netzwerkkarte im Rechner die alle am besten deaktiviert werden müssen den Router abbauen und zum Rechner schleppen ect....
Wie gesagt geht, ist aber nicht wirklich praktikabel und es soll ja uch per Update funktionieren.
 
Einfach die erste Version signieren, "umständlich" installieren und danach (selbst signierte) Updates bequem über das AVM-GUI installieren.
Auf alles Seiten die ich gefunden habe steht das ich einfach nur das image über das Webinterface flashen kann.
Wo steht denn, man könne eine nicht signierte Image-Datei oder eine eigene Firmware "beim ersten Mal" einfach so über das AVM-GUI hochladen? Diese Quelle sollte dann dringend korrigiert werden (verhindert weitere Threads von Leuten, die davon in die Irre geleitet werden, so wie Du offenbar in #1) - oder Du hast vielleicht doch nur die falschen Seiten gefunden.
 
Wo steht denn, man könne eine nicht signierte Image-Datei oder eine eigene Firmware "beim ersten Mal" einfach so über das AVM-GUI hochladen? Diese Quelle sollte dann dringend korrigiert werden (verhindert weitere Threads von Leuten, die davon in die Irre geleitet werden, so wie Du offenbar in #1) - oder Du hast vielleicht doch nur die falschen Seiten gefunden.

Das kam dann wohl falsch rüber. Mir ist schon klar, und so habe ich das auch gemeint, das dass aufspielen des Freetz-NG Images natürlich beim ersten mal nur "umständlich" über z.B. MAKE PUSH-FIRMWARE funktioniert. Es geht mir hier rein um das UPDATE auf eine neue Version von einem freetz-ng Image auf ein neues freetz-ng Image / ein Image mit neuen oder anderen Modulen.

Einfach die erste Version signieren, "umständlich" installieren und danach (selbst signierte) Updates bequem über das AVM-GUI installieren.

Und genau das funktioniert halt nicht.
Wenn ich das richitg verstanden habe ist dafür folgendes zu tun /kontrollieren: In Menuconfig hab ich das Level auf "Expert" gesetzt um die Einstellung überhaupt zu sehen und zu kontrollieren. Unter Firmware packing (fwmod) options dann Sign image file auswählen und ein Passwort festlegen. Bei mir war es bereits aktiviert und das Standartpasswort war auch drin. Hab es auch schon mit einem eigenen Passwort versucht, ändert nichts daran das ein neues Image nicht über das Web Interface geflasht werden will. Und bevor dann jetzt die Frage kommt ob es beim flashen des neuen Images auch das gleiche Passwort war wie beim ersten flashen um Freetz-NG überhaupt drauf zu bekommen JA. Extra ein Image erstellt und "umständlich" per push-firmware drauf getan und dann ein neues image mit zusätzlichen Modulen erstellt und ein Update versucht. Das ganze sowohl mit dem Standartpasswort freetz als auch mit einem eigenen.
 
Und bevor dann jetzt die Frage kommt ob es beim flashen des neuen Images auch das gleiche Passwort war wie beim ersten flashen um Freetz-NG überhaupt drauf zu bekommen JA.
Das Entscheidende ist nicht das Passwort - wichtig ist, daß man denselben Key zum Signieren verwendet und das klappt (a) nur dann, wenn man dasselbe System für das erste und folgende Images verwendet oder (b) zumindest seine einmal generierten Key-Files aus dem verwendeten System so sichert, daß man sie beim nächsten Mal VOR dem Schritt, wo letztlich fwmod aufgerufen wird (wenn's durchläuft, ist das schon das nackte make), wieder restaurieren kann (https://github.com/Freetz-NG/freetz-ng/blob/b8d6d8fb9faf162417eb9f46df87403a77f8ee18/fwmod#L1830).

das Standartpasswort war auch drin. Hab es auch schon mit einem eigenen Passwort versucht
DAS paßt dann eher dazu, daß da entweder nicht erfolgreich signiert werden konnte (wenn ein vorhandener Key mit einem geänderten - und damit falschen - Kennwort geöffnet werden soll - wobei das Kennwort m.W. in fwmod geprüft wird) oder daß eben bei jedem make in Freetz-NG doch wieder ein neuer Key generiert wird (warum auch immer) und der kann dann natürlich auch ein anderes Passwort verwenden.

Das Prinzip beim Signieren ist nun mal so, daß sich der öffentliche Schlüssel, der zu dem privaten Key paßt, mit dem das neue Image signiert wurde, bereits in der laufenden Firmware befinden muß - daher klappt das Update mit Signatur eben immer erst im zweiten Anlauf (von da an dann aber immer, wenn man den richtigen Key im Image hat). Das Passwort ist ausschließlich dazu da, den privaten Key gegen unbefugten Zugriff zu schützen - das hat mit der Signatur eines Images und mit dessen Upload auf die Box (ich nehme mal an, das meinst Du mit "flashen") also nur am äußersten Rand zu tun (weil ohne den privaten Schlüssel nicht signiert werden kann).



Wenn Du der Ansicht bist, auch das wäre alles bei Dir der Fall (Du hast ja einiges unternommen/geschrieben, um nicht mit weiteren "dummen Fragen" gelöchert zu werden - nur gewinnt man halt (zumindest mir geht das so) oben den Eindruck, daß Du das Prinzip nicht so 100% verstanden hast, was aber nicht heißen muß, daß es nicht dennoch richtig umgesetzt wurde (in/von fwmod), solange man tatsächlich den einmal irgendwo im Home-Verzeichnis angelegten Key auch wiederverwendet (bewußt oder unbewußt) und zwar "für ewig"), kannst Du ja mal Dein selbst signiertes Image prüfen: [Info] Wie funktioniert eigentlich das Signieren der AVM-Firmware? + https://github.com/PeterPawn/YourFritz/tree/main/signimage - den dazu notwendigen (eigenen) öffentlichen Schlüssel findest Du in dem Image, das gerade auf der 6591 läuft.

In dem oben verlinkten Thread finden sich auf den letzten Seiten (es sind insgesamt ohnehin nur vier bisher, iirc) auch Infos, wie man die Signatur mit einer Shell auf der Box selbst prüfen kann - entweder mit den angebotenen Skript-Files (wenn man ein passendes openssl-Binary im Image hat - ansonsten kann man sich auch eines einbauen lassen, auch wenn man das neue Image damit dann erneut "mühsam" installieren muß) oder auch mit den Bordmitteln von AVM.

Nur wenn das Image diese Signaturprüfung besteht (ich gehe mal davon aus, daß hier nicht schon wieder dasselbe Problem vorliegen wird, welches zuletzt im Signatur-Thread behandelt wurde und das könnte man dann wieder durch passende Änderung der Größe des Payloads umgehen), hat es überhaupt eine Chance, über das AVM-GUI installiert zu werden (wobei es dann über TR-064 auch geht).

Ansonsten kann man auch - zu Testzwecken - das Signieren durch Freetz-NG weglassen (das arbeitet anders als meine Lösung) und alles mit den Skripts aus signimage probieren (dann darf nur noch keine Signatur im Image sein, daher muß man es in Freetz-NG dafür abschalten) - das wäre zumindest dann eine Option, wenn man das "Reste-Problem" ausschließen will (von dem ich immer noch nicht weiß, ob es bei Freetz-NG auch auftreten könnte: https://github.com/PeterPawn/YourFritz/discussions/42).

Letztlich hängt alles nur davon ab, wie intensiv Du auf der Suche nach der Möglichkeit, selbstsignierte Images zu installieren, sein willst ... das Problem kann hier an allen möglichen Stellen liegen. Daß die Installation über das Freetz-GUI bei manchen Modellen nicht wie erwartet funktioniert, ist auch ein bekanntes Problem - auch dazu gibt es einige Threads. Aber über das AVM-GUI sollte es klappen - wenn die Signatur stimmt. Denn dann passiert da letztlich auch nichts anderes, als wenn man ein original von AVM signiertes Image verwendet.
 
  • Like
Reaktionen: prisrak1
Sorry wenn ich das so deutlich schrieben muss, aber wie das Prinzip des signierens funktioniert ist mir klar. Mir war nur nicht klar das ich auch noch jeden Furz schreiben muss wie ich eine neue Signatur mit neuem Passwort für einen Durchgang für das erstellen eines Images, dem flashen dieses Images per push-firmaware, dem erstellen eines neuen Images auf dem gleichen Rechner und dem versuch das dan per Webinterface zu flashen aufdröseln muss.

Ich werde mich mal ran setzen und die Signaturen untersuchen, denke aber das das nicht das Problem ist. Hatte schon das Problem das die Signaturen nicht zueinander gepasst hatten und da kam eine andere Fehlermeldung beim flashen über das AVM Webinterface. Weiß nur nicht mehr was genau es war, irgendwas mit Signature fail..... blaa...Die Meldung kommt aber nicht

Danke schonmal für deine Hilfe.
 
Danke schonmal für deine Hilfe.
Gern geschehen.

Mir war nur nicht klar das ich auch noch jeden Furz schreiben muss
Flatulenzen interessieren (mich zumindest) nicht wirklich ... aber wenn man sein Problem - gerne ohne Darmwinde wie gesagt - nicht so beschreibt, daß der Leser auch erkennen kann, was man alles richtig gemacht hat, muß man eben damit leben, wenn man auch noch einmal "das Offensichtliche" als Vorschlag erhält.

Wenn man tatsächlich DER Leuchtturm in der Masse der Anwender ist, die das gerne auch mal falsch benutzen, dann muß man es entweder selbst gleich verständlich und ausführlich beschreiben oder man muß eben damit leben, wenn die Leser das dann nicht auf Anhieb verstehen. Wer hätte es eigentlich in der Hand, das so zu (be-)schreiben, daß keine Zweifel mehr möglich sind? Ich habe da einen Verdacht.
 
Abgesehen von einer evtl. vorh. Signierungsproblematik eine kleine Bemerkung:

Ich habe nicht die Standart IP Range, die FB hängt hinter nem Switch, ...

Ich auch nicht. Kann aber dennoch ohne Änderungen an der Netzwerkverkabelung und ohne Änderung der IP-Konfiguration des PC jederzeit bspw. eine Firmware per Bootloader auf meine (Haupt)-Fritzbox installieren, ohne großen Aufwand. Das einzige aufwändige dabei ist tatsächlich die dazu erforderliche kurze Unterbrechung der Stromzufuhr der Fritzbox, weil ich dazu erst 2 Treppen hinuntersteigen muss.
Möglich ist das, indem man bspw. eva_discover nutzt damit der Bootloader über eine zum lokalen Subnetz passende IP erreichbar ist oder auch indem man beim betreffenden PC bzw. VM ein weiteres passendes IPv4 (Sub)-Netz einrichtet beim entsprechenden Netzwerkinterface (das geht dann auch ausschließlich mit push-firmware).
 
  • Like
Reaktionen: prisrak1
Wenn man tatsächlich DER Leuchtturm in der Masse der Anwender ist, die das gerne auch mal falsch benutzen, dann muß man es entweder selbst gleich verständlich und ausführlich beschreiben oder man muß eben damit leben, wenn die Leser das dann nicht auf Anhieb verstehen. Wer hätte es eigentlich in der Hand, das so zu (be-)schreiben, daß keine Zweifel mehr möglich sind? Ich habe da einen Verdacht.
Das würde aber jetzt in einer Grundsatzdisskusion ausarten was man alles als "Grundkenntnisse" vorraussetzt ;)

Ich bin davon ausgegangen, das wenn sogar ich als blutiger Anfänger weiß, das dass erstellen eines Images mit falschem Passwort zu einer Fehlermeldung im make Prozess kommt, mir jeder der helfen kann das auch weiß und ich das nicht extra schreiben muss.

Aber egal, hat ne weile gedauert bis ich das endlich alles gelesen habe. mit dem -b Paramter ist alles in Ordnung, aber wenn ich -s nutze findet er keinen public key

Code:
root@fritz:/var/mod/root# ./check_signed_image 6591_07.29.ger_freetz-ng-18693-b8d6d8fb9_20211123-040036.image -b
Found OpenSSL 1.1.1l  24 Aug 2021
Check dgst command ... OK
Check rsautl command ... OK
HWRevision mismatch between shell and urlader environment (233 vs. 233) ignored.
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key2 ... FAILED
Checking the public key from /etc/avm_firmware_public_key3 ... FAILED
Checking the public key from /etc/avm_firmware_public_key8 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
root@fritz:/var/mod/root# ./check_signed_image 6591_07.29.ger_freetz-ng-18693-b8d6d8fb9_20211123-040036.image -s
Found OpenSSL 1.1.1l  24 Aug 2021
Check dgst command ... OK
Check rsautl command ... OK
HWRevision mismatch between shell and urlader environment (233 vs. 233) ignored.
Check x509 command ... OK
Trying to read public key from /var/flash/websrv_ssl_cert.pem ... OK
Checking the public key from FRITZ!OS certificate ... FAILED
No usable public key was found.

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Das mochte das Netzwerk bei den letzuten Versuchen so gar nicht. Nach einigen Versuchen war dann der DHCP Server und so einiges anderes nicht erreichbar. Ich vermute an der Stelle das der Switch das nicht mag.

Edit: Hab nicht alle parameter probiert gehabt beim ersten Versuch.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Mir ist gerade eingefallen das es ja als Versuch ein Image ohne die AMV puplic keys war.... flashe eben mal eines mit den keys drin und versuche dann nochmal die Signaturprüfung.

Code:
root@fritz:/var/mod/root# ./check_signed_image 6591_07.29.ger_freetz-ng-18693-b8d6d8fb9_20211123-044057.image -b
Found OpenSSL 1.1.1l  24 Aug 2021
Check dgst command ... OK
Check rsautl command ... OK
HWRevision mismatch between shell and urlader environment (233 vs. 233) ignored.
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... FAILED
Checking the public key from /etc/avm_firmware_public_key2 ... FAILED
Checking the public key from /etc/avm_firmware_public_key3 ... FAILED
Checking the public key from /etc/avm_firmware_public_key8 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
root@fritz:/var/mod/root# ./check_signed_image 6591_07.29.ger_freetz-ng-18693-b8d6d8fb9_20211123-044057.image -s
Found OpenSSL 1.1.1l  24 Aug 2021
Check dgst command ... OK
Check rsautl command ... OK
HWRevision mismatch between shell and urlader environment (233 vs. 233) ignored.
Check x509 command ... OK
Trying to read public key from /var/flash/websrv_ssl_cert.pem ... OK
Checking the public key from FRITZ!OS certificate ... FAILED
No usable public key was found.

Bleibt sich gleich mit dem AVM public keys
 
Zuletzt bearbeitet von einem Moderator:
Das Signieren bzw. Signaturprüfen mit dem Key auf der Box hat mit einem Update nichts zu tun - das ist nur für Fälle gedacht, wo man Dateien VON und AUF der Box signieren will, weil man sie an irgendeinem anderen Ort speichern möchte und (nach dem Transfer zurück auf die Box) sichergehen möchte, daß sie zwischenzeitlich nicht geändert wurden bzw. von genau dieser Box stammen (wobei man dann den Key auch sichern muß/sollte, weil AVM beim Reset o.ä. einfach einen neuen generiert). DAS ist also schon mal kein Problem, was nicht zu erwarten gewesen wäre.

Wenn der richtige Public-Key auf der Box ist (und das sagt check_signed_image ja dann von dem mit Index 8), dann wäre halt die nächste Frage, was die AVM-Komponenten denn über dieses File zu berichten haben. Irgendein Return-Code von tr069fwupdate (das habe ich im Signatur-Thread gerade erst wieder ein paar Mal gezeigt, wie man das aufruft/benutzt), der über 200 liegt, deutet auf ein Problem mit dem Aufbau des Images hin. Hier KÖNNTE man dann tatsächlich wieder annehmen, daß es ein Resteproblem ist - worum es dabei geht, wurde gerade in den letzten Beiträgen im Signatur-Thread beschrieben/getestet - WENN der Return-Code von tr069fwupdate denn auch 210 sein sollte.

Da meines Wissen bei derartigen Problemen mit Freetz(-NG) i.d.R. die Benutzer dann einfach zur Installation über EVA greifen, ist bisher noch nie richtig getestet worden (auch von @cuma nicht, wie er mir schrieb), ob die Lösung mittels GNU-tar, openssl und Hinzufügen der Signatur mit tar --append ebenfalls von diesem "Resteproblem" betroffen ist oder nicht (s. Link weiter oben zur Diskussion im YourFritz-Repo).

Die nächste Frage ist also: Was gibt denn tr069fwupdate packet für einen Return-Code für dieses Image aus? Irgendetwas mit 6 wäre zu erwarten (falls es an den Pfaden in /var/install dann scheitert) - ansonsten muß man schauen, was in den AVM-Protokollen beim Update-Versuch über das GUI steht.

EDIT: Die "Fehlermeldung" mit dem "mismatch" bei der HWRevision ist natürlich auch falsch (war eines meiner letzten Updates und stimmt offensichtlich nicht), das sehe ich mir noch einmal an.
 
Keine Ahnung ob ich das richtig gemacht habe, aber hier ist das Ergebnis
Code:
root@fritz:/var/mod/root/signimage# tr069fwupdate packet file:///var/mod/root/signimage/6591_07.29.ger_freetz-ng-18693-b8d6d8fb9_20211123-073648.image ; echo rc=$?
rc=1
root@fritz:/var/mod/root/signimage# cat /var/tmp/firmware_stream_result
total=65689600 ret=0 sub_ret=0 sigcrc=3c0c3c38f1316feb50d3f5b5930e0bcb
 
Das sieht so weit alles normal aus - Return-Code 1 heißt "SUCCESS_REBOOT". Bei diesem Return-Code müßte eigentlich /sbin/burnuimg schon gelaufen sein (bei den Puma7-Geräten werden die Partitionen nicht einzeln in /var/install beschrieben, sondern das übernimmt das genannte Tool), weil das direkt von tr069fwupdate bzw. firmwarecfg aufgerufen wird.

Dadurch, daß tr069fwupdate beim Aufruf mit packet aber eine andere Verzeichnisebene verwendet (/var/packet als Basisverzeichnis, anstelle von /), wird die uimg-Datei sicherlich in /var/packet/firmware-update.uimg gelandet sein, wo sie burnuimg nicht finden kann, obwohl dieses Tool eigentlich den Pfad zur Image-Datei als Parameter kriegt (deshalb findet man darin auch keine Zeichenketten mit einem "festen" Dateinamen).

Man kann das Tool natürlich auch selbst aufrufen - Parameter sollte es (AVM-typisch) mit -? preisgeben und afaik müßte der Aufruf aus den anderen Komponenten heraus: /sbin/burnuimg -s <image_name> lauten, wobei das -s wohl für "silent" steht und beim manuellen Aufruf vielleicht ausgelassen werden sollte.

Aber das alles sollte auch beim Aufruf aus den anderen Komponenten von AVM in Dateien unterhalb von /var/tmp ordentlich protokolliert sein, für beide Standard-Output-Handle gibt es üblicherweise eine Redirection in eine Datei dort. Wobei ich keine Puma7-Box habe und daher auch keine "Vorlage" für eine erfolgreiche Installation kenne - aber an den Signaturen liegt es schon mal (ziemlich sicher) nicht, denn die stimmen jetzt.

EDIT: Wobei es auch gut sein kann, daß tr069fwupdate packet gar kein burnuimg aufruft, weil es ja eigentlich keine zu installierende Firmware für die Box erwartet(!) - das ist ja der Aufruf, der zur Installation bzw. zum Bereitstellen der Firmware für Zubehör von AVM verwendet wird. Das sollte bei firmwarecfg (also beim Update über das GUI) dann aber anders aussehen.

Und falls sich jemand fragt, warum die Installation über das Freetz-NG-GUI nicht funktioniert bei diesen Modellen - eben das burnuimg macht hier den Unterschied. Freetz-NG packt die Image-Datei auch nur aus und ruft dann seinerseits irgendwann /var/install (aus der ausgepackten Datei) auf. Das ist bei diesen Modellen aber lange nicht dasselbe, wie bei anderen - hier passiert in diesem Skript nur sehr, sehr wenig und schon gar kein Schreiben in irgendwelche persistenten Speicher.
 
Zuletzt bearbeitet:
Das heißt dann also ich muss mich dann mit der push-firmware Methode zufrieden geben?
 
Das habe ich so nicht geschrieben - ganz im Gegenteil. Da steht in #13 ja wohl deutlich, daß der nächste Test jetzt über das GUI erfolgen sollte und dabei dann alle Stellen anzusehen sind (und natürlich auch zu zeigen), wo Protokolle abgelegt werden. Auch wenn Du es vermutlich wieder "verschweigen" willst - ich wüßte nicht, daß ich bisher irgendetwas überlesen hätte, wo von einem erneuten Datei-Update mit genau dieser Image-Datei, die ja nun nachweislich die Signaturprüfung bestanden hat, berichtet wurde. Irgendwelche "Implikationen" zählen dabei nicht bzw. darauf lasse ich mich nicht ein, wenn ich hier Zeit investieren soll. Es kann nicht soo schwer sein, das noch einmal zu testen und dann die Ergebnisse dieses Tests auch (umfassend) zu präsentieren.

Das Witzige an diesen Boxen mit zwei Systemen ist es obendrein, daß man (wie bei den meisten anderen Modellen halt auch - nur bei reinen NOR-Modellen mit nur einem System ist das etwas schwieriger, aber ebenso nicht unmöglich) einfach nur die Firmware irgendwie auf die Box bringen muß und dann kann man sie - bei vorhandenem Shell-Zugang und den muß man ja nicht entfernen - auch "von Hand" installieren. Wie das bei anderen Modellen geht, habe ich hier auch irgendwo ausführlich erläutert (sowohl für VR9- als auch GRX-Boxen - ja, sogar bei IPQ-basierten Modellen sollte das auf diesem Wege möglich sein) ... und wenn ich #13 noch einmal lese, erkenne ich da irgendwie auch den Vorschlag, das Update bei diesem Modell notfalls auch mit burnuimg anzuwerfen, um überhaupt erst einmal zu sehen, ob das arbeitet und was dabei (ohne den "silent"-Switch) ausgegeben wird.

Letztlich kocht auch die AVM-Methode des Flash-Updates nur mit Wasser und es spricht nichts dagegen, das bei Bedarf auch von Hand nachzumachen - notfalls sogar "für immer", falls man sich nicht länger mit Signaturen befassen will. Wobei es da beim (automatischen, wenn auch manuell angeworfenen) Installieren durch die AVM-Firmware eigentlich auch keine echten Geheimnisse gibt - ja, sogar AVM speichert seit einer Weile (soo lange ist das noch gar nicht her, ca. 3-4 Jahre würde ich sagen) die Ausgaben der Installation in den bereits mehrfach erwähnten Dateien im tmpfs - da kann man die auch ansehen.

Und wenn das mit manuellem Aufruf von burnuimg dann funktioniert und damit burnuimg nicht die eigentliche Ursache sein sollte (was ich ohnehin nicht glaube - ich bleibe ja dabei, daß ich erst mal ein erneutes Update über das GUI machen und mir dann die Protokolle ansehen würde, denn schon darin sollte man erkennen können, ob es überhaupt aufgerufen wurde und wo ggf. noch Fehler aufgetreten sind), dann muß man eben von dort an wieder rückwärts suchen.

Nämlich ob das burnuimg in diesem Falle auch wirklich aufgerufen wurde und wenn ja, wie genau. Und auch das ist bei vorhandenem Shell-Zugang wieder simpel (wenn's nicht ohnehin in irgendeinem Log steht) - man kopiert sich dazu einfach das Binary an eine andere Stelle in der Box und ersetzt es am Ursprungsort durch ein Shell-Skript (per bind-Mount), in dem man - vor dem Aufruf des Kommandos am Sicherungsort - die Parameter, mit denen das Skript aufgerufen wurde, irgendwohin protokolliert, wo man sich das anschließend wieder ansehen kann. EDIT: Und da gehört dann auch der Prozessbaum und die Prozessliste dazu - denn darin kann man erkennen, von wo das Ganze aufgerufen wurde.

Wie ich bereits schrieb - ich bin gerne bereit, mir Ergebnisse der von mir vorgeschlagenen Tests anzusehen und zu versuchen, die dann zu interpretieren. Wieviel weiteren Aufwand DU jetzt an dieser Stelle investieren willst, mußt Du auch selbst entscheiden - es sind längst noch nicht alle Optionen ausgeschöpft.
 
Also beim Updateversuch über das AVM Webinterface wird mir nach wie vor der Seite aus #1 angezeigt. In den Log Einträgen unter System steht dann
Code:
FRITZ!OS-Update nicht erfolgreich. Fehlergrund: Interner Fehler beim Installieren der neuen FRITZ!OS-Version [6.13]

in /var/tmp/fwupdate.log
Code:
11:56:47 firmwarecfg(10286): starting firmware update via command 'UploadFile'
11:56:47 firmwarecfg(10288): delayed reboot helper process waiting for pid 10286 to terminate
11:56:47 firmwarecfg(10286): get_file with max_size=734003200
11:56:51 firmwarecfg(10286): waiting for the tar process to terminate
11:56:51 firmwarecfg(10286): tar process terminated
11:56:51 firmwarecfg(10286): signature ok
11:56:51 firmwarecfg(10286): prepare_firmware_upgrade returns g_status=0
11:56:51 firmwarecfg(10286): now_install
11:56:53 firmwarecfg(10286): calling /var/install
11:56:53 firmwarecfg(10286): waiting for /var/install to complete
11:56:53 firmwarecfg(10431): Running /var/install
11:56:53 firmwarecfg(10286): /var/install exited normally with status=1
11:56:53 firmwarecfg(10286): /var/install returned  g_status=1
11:56:53 firmwarecfg(10286): burnuimg starting ...
11:56:53 firmwarecfg(10286): ERROR burnuimg status=5120
11:56:53 firmwarecfg(10286): ERROR burnimage_uimg failed
11:56:53 firmwarecfg(10286): killing delayed reboot helper process 10288
Beim aufrufen von /sbin/burnuimg /var/mod/root/firmware-update.uimg
Code:
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

Wenn du noch etwas brauchst, schreib einfach nur kurz wo ich das finden kann was du willst. Ich habe nämlich keine Ahnung was du alles brauchst oder weas relevate Daten sind die ich hätte schreiben können.

Edit:
Ich habe im freetz-ng Interface mal Syslog eingeschaltet und nochmal ein Update über das AVM Interface versucht. Auch dabei erscheint der Eintrag wie beim manuellem aufrufen von burnimg
Code:
Nov 24 13:16:12 fritz user.err burnuimg[15540]: <<< 500 Invalid sector "-1".
 
Zuletzt bearbeitet:
Also ist das Problem damit schon mal definitiv auf das burnuimg heruntergebrochen - damit kann man alles andere erst mal außer Acht lassen und auch weitere Tests auf direkte Aufrufe dieses Programms beschränken, bis man eine Version der Image-Datei hat (hier geht es dann um die innere firmware_update.uimg und nicht mehr um das TAR-File außen herum), die vom AVM-Programm klaglos akzeptiert wird.

Das Programm zum Behandeln von uimg-Dateien (Intel Unified Image) stammt von Felix Schmidt (mal @fesc2000, hier nur @fesc) und wird auf mehreren Plattformen angeboten:

- https://github.com/fesc2000/ffritz/tree/master/src/uimg
- https://bitbucket.org/fesc2000/ffritz/src/6591/src/uimg/

Ob und wie genau sich diese Versionen jetzt unterscheiden, muß man sich ggf. als Nächstes ansehen - ebenso wie die Frage zu klären ist, woher Freetz-NG seine Version letztlich bezieht.

DASS sich die Versionen unterscheiden, läßt sich hingegen im Handumdrehen ermitteln:
Rich (BBCode):
peh@vidar:~> mkdir -p /tmp/ffritz && cd /tmp/ffritz
peh@vidar:/tmp/ffritz> git clone https://bitbucket.org/fesc2000/ffritz.git bitbucket
Cloning into 'bitbucket'...
Receiving objects: 100% (5175/5175), 41.81 MiB | 11.84 MiB/s, done.
Resolving deltas: 100% (2822/2822), done.
peh@vidar:/tmp/ffritz> git clone https://github.com/fesc2000/ffritz.git github
Cloning into 'github'...
remote: Enumerating objects: 4142, done.
remote: Counting objects: 100% (850/850), done.
remote: Compressing objects: 100% (456/456), done.
remote: Total 4142 (delta 437), reused 677 (delta 307), pack-reused 3292
Receiving objects: 100% (4142/4142), 45.98 MiB | 5.28 MiB/s, done.
Resolving deltas: 100% (2404/2404), done.
peh@vidar:/tmp/ffritz> pushd bitbucket; sha256sum src/uimg/*; popd
/tmp/ffritz/bitbucket /tmp/ffritz
083b7a4e6c864575984d1ea624ab14beba9589bd370d33fc42db220926c318a6  src/uimg/Makefile
2ef207947b217778d3e084f3df42208c6342a3a262063d901093411f6ccf0317  src/uimg/uimg.c
f813115ebbca391fb71ab287c6d3bcfb2682ecad83f9b461844439d890039d1e  src/uimg/uimg.h
/tmp/ffritz
peh@vidar:/tmp/ffritz> pushd github; sha256sum src/uimg/*; popd
/tmp/ffritz/github /tmp/ffritz
f257ebb08b74b66af0d4d85fa73cbaa23d3f963ad2f23274ce339078a25d0d04  src/uimg/Makefile
6e76612b5b44ef7f4e24827e61217ea3b1156a4f8c00f852e0b4798de55730dc  src/uimg/uimg.c
f5881602b2b5e8cda8251f16f07a588adf58d6bff3d0dfdf4745e9b1e306be3b  src/uimg/uimg.h
/tmp/ffritz
peh@vidar:/tmp/ffritz>
und in Freetz-NG wird offensichtlich die Version von BitBucket genommen (was vermutlich auch die "führende" ist). Hier könnte/müßte @fesc ggf. mal die Repos synchronisieren, damit die vorhandenen Unterschiede nicht länger zu "offenen Fragen" führen.

Ansonsten beschwert sich burnuimg da ja offenbar über einen ungültigen Wert ... was aber gleichzeitig auch dessen Arbeitsweise offenlegt. Allem Anschein nach wird das zu schreibende Image auf den von beiden Systemen gemeinsam genutzten Update-Pfad geschrieben (das kann eine eMMC-Partition sein oder auch ein weiteres tmpfs, iirc in beiden Systemen unter /var/tmp/remote gemountet) und dann der ARM-Core über den "glue daemon" (über den beide Systeme kommunizieren können, mit definierten Aktionen) angewiesen, die Daten aus diesem Image zu installieren. Damit sieht man auf dem ATOM-Core auch nichts weiter davon ... nur den Start (uimg update - und auch das nur bei manuellem Aufruf, ansonsten wird das -s die Meldungen wohl unterdrücken) und die anschließende Fehlermeldung (500 Invalid sector "-1".) - der Rest läuft auf dem ARM-Core ab und es braucht deutlich mehr Aufwand, den dort auch noch zu verfolgen (was auch gut so ist, von Modifikationen/Eingriffen auf dem CM sollte man Abstand nehmen).

Mal schauen, ob sich @fesc wg. der "Referenz" hier meldet und mit der Fehlermeldung aus dem Stand etwas anfangen kann, weil vielleicht sein Tool irgendwelche unbekannten Felder in der uimg-Struktur mit -1 initialisiert. Wenn nicht (bezogen auf das "Melden"), schaue ich mir das bei Gelegenheit mal an - aber ich hatte bisher (wie schon mal festgehalten) noch keine Notwendigkeit, Puma7-Boxen mit einer eigenen uimg-Datei zu beglücken und habe mich daher auch mit dem Format noch nicht befaßt.

Ein schnelles diff über die beiden Versionen zeigt aber auch, daß die bei BitBucket wohl die aktuellere ist (einige struct-Member sind nicht mehr "unknown", sondern haben einen richtigen Namen) - vielleicht kann @fesc ja die Frage beantworten, ob das bei ihm auch mit dem burnuimg funktioniert, wenn er die firmware-update.uimg mit der BitBucket-Version zusammengestellt hat.

Auf alle Fälle geht es vorwärts ... das ist ja auch schon mal eine gute Nachricht. Es liegt also weder am Signieren, noch am Inhalt der /var/install in der Image-Datei. Die schlechte Nachricht ist es dann wieder, daß DU die derzeit bei Dir vorhandenen firmware-update.uimg-Dateien dann aber doch nicht über die Shell installieren kannst - diese Option ist also (zumindest temporär) auch nicht verfügbar und wenn das Problem geklärt ist, funktioniert (aller Wahrscheinlichkeit nach) dann auch gleich die Installation über's GUI wieder.

EDIT: Wobei man/Du auch mal schauen kann(st), ob das neue uimg-File tatsächlich auf der Partition liegt, die beide Systeme gemeinsam nutzen (theoretisch müßte die ja im ATOM-Core r/w sein und im ARM dann r/o oder auch nur bei der Aufforderung uimg update gemountet werden) ... das ist bisher ja nur eine Vermutung meinerseits, auch wenn der ARM-Core ja irgendwie an diese Datei kommen muß. Wenn ich Dateien bei Puma-Boxen von AVM aus dem ARM-Core holen will, schreibe ich die i.d.R. mit den ftpput-/ftpget-Applets der BusyBox auf den FTP-Server auf dem ATOM-Core, den man unter der 169.254.1.1 erreichen kann - der ARM-Core sollte die 169.254.1.2 an dieser Stelle verwenden und über (iirc) arm_console (oder wie auch immer das beim Puma7 dann von AVM genannt wurde - letztlich ist es ein Pipe-Server, der auf eine Shell auf dem ARM-Core zeigt, die auch über den "glue daemon" gestartet wird) kann man zumindest solche einfachen Kommandos auch auf dem ARM-Core (und zwar OHNE Änderungen an diesem Teil des FRITZ!OS) ausführen lassen.
 
Zuletzt bearbeitet:
  • Wow
Reaktionen: jha4711
Ich habe kein Verzeichnis /var/tmp/remote bei einem Updateversuch oder vorher / nachher. Entweder ist es woanders oder wird nicht erstellt. Oder ich hab nur nie den richtigen Zeitpunkt abgepasst zum nachschauen.
Kann man das loggen beim Updateversuch?
 
Irgendwo im Filesystem steht ein Init-Skript (/etc/init.d/E16-filesystem-update), wo man die korrekten Pfade nachlesen kann - beim Puma7 kenne ich das (oben schon "zugegeben") nicht im Detail und bei den Puma6-Modellen hat AVM da im Laufe der Zeit auch geändert (auch wenn bei 6490/6590 m.W. noch kein Intel Unified Image verwendet wurde). Nach dem Inhalt dieses Skripts müßte es eine Partition mit dem Bezeichnung update_tmp geben (in /proc/avm_partitions) und die wird dann unter /var/remote gemountet. DAS müßte diese Austausch-Partition sein, wobei ich das bei einer Puma7-Box eben noch nie selbst untersucht habe - da mußt Du jetzt halt mal etwas Phantasie beweisen und mit ein paar Kommandos selbst auf die Suche gehen.

Am einfachsten schaut man mal mit mount nach, was da überhaupt eingebunden wird, in der /proc/avm_partitions findet man die Namen der Devices und Partitions und wenn man tatsächlich mount-Aufrufe mitloggen will, ginge das wieder über die (iirc weiter oben in diesem Thread) schon einmal erwähnte Vorgehensweise, das mount-Kommando im System mit einem Wrapper-Skript zu ersetzen (ich nehme mal an, daß AVM da ganz normal mount aufrufen würde (wenn überhaupt "dynamisch" gemountet wird) und nicht direkt die Syscalls verwendet). Auch blkid sollte vorhanden sein (zeigt die gefundenen Block-Devices (Storage/Partitionen) an und die gefundenen Dateisysteme).

Wobei ein Blick auf die Libraries, die von burnuimg eingebunden werden, mich eher daran zweifeln läßt, daß dort tatsächlich (erst) das Kopieren der Datei auf eine Austausch-Partition stattfindet (zumindest in der /sbin/burnuimg auf dem ATOM-Core) - da sind keine (dateibasierten) I/O-Funktionen zu finden und auch (außer aicmd_docommand) nichts, was sich nach "Kommando ausführen" anhört:
Rich (BBCode):
vidar:/home/FritzBox/FB6591/ATOM $ nm -D sbin/burnuimg
0000146c R _IO_stdin_used
         w _ITM_deregisterTMCloneTable
         w _ITM_registerTMCloneTable
00003070 B __bss_start
         w __cxa_finalize
         w __gmon_start__
         U __libc_start_main
         U __stack_chk_fail
00003070 D _edata
00003098 B _end
         U _getargs
         U _getargs_init
         U aicmd_docommand
         U avmipc_create
         U avmipc_destroy
         U avmipc_msg_register
         U crashdump_init
         U csock_add_streamfd
         U csock_close
         U csock_copy_from_ibuf
         U csock_exit
         U csock_get_writecbuf
         U csock_getline
         U csock_iflush
         U csock_output_bytes_leftq
         U csock_printf
         U csock_remove_fd
         U csock_select
         U csock_select_with_msecs
         U csock_sendfile
         U csock_setobuf
         U ctrlerrmsg
         U debug_gethandle
         U debug_option
         U debug_set
00000ba0 T main
         U opt_usage
         U setpgmname
         U signal
         U strcmp
         U strstr
vidar:/home/FritzBox/FB6591/ATOM $
, dafür aber offensichtlich Funktionen, um Daten über einen Socket zu senden.

Da aber obendrein auch die Funktionen zum Lesen von Dateien fehlen (wenn man nicht bei einem csock_sendfile tatsächlich auch einen Namen angeben kann in irgendeiner Variante), könnte ich mir auch gut vorstellen, daß der pumaglued erst dafür zuständig ist (der läuft auf dem ARM-Core und mit dem wird vermutlich über das aicmd_docommand kommuniziert), die Daten vom ATOM- auf den ARM-Core zu schaffen, wenn der sein uimg update-Kommando kriegt ... oder vielleicht liest der die auch "live" vom ATOM-Core (dann aber vermutlich auch nicht direkt aus /var), wobei mir dafür wieder die Anzeichen in der (oben protokollierten) Kommunikation mit ihm fehlen, denn es macht ja nur wenig Sinn, dem burnuimg einerseits einen Parameter für den Dateinamen zu spendieren und andererseits ein firmware-update.uimg irgendwo fest zu verdrahten. Und irgendwie müßte dann ja auch der pumaglued erfahren, welche Datei er eigentlich benutzen soll für das Update ...



Was man ggf. noch machen könnte (wobei das immer weitergehende Kenntnisse verlangt), wäre die Verwendung eines strace (sollte sich mit Freetz-NG bauen lassen), um die Systemaufrufe von burnuimg mal zu protokollieren - aber auch das ist nur ein weiterer "Ansatz", wenn einem ansonsten nichts mehr einfällt, weil letztlich die eigentlichen Syscalls (die man damit protokolliert) ja gar nicht aus dem Binary direkt erfolgen, sondern aus irgendwelchen Libraries, die von diesem eingebunden werden und für alles fehlen die Quellen. Man kriegt damit also auch nur einen begrenzten "Ablaufplan" und kann vielleicht noch sehen, ob da Daten aus einer Datei in einem VFS gelesen werden und welche das ist.

Eigentlich soll diese "Kontrolle" auch nur sicherstellen, daß tatsächlich die richtige Datei auf dem ARM-Core verarbeitet wird (also der irgendwie auf die uimg-Datei zugreifen kann) und der berichtete Fehler nicht daher kommt, daß schon dieser Zugriff nicht möglich ist (warum auch immer das dann so sein könnte).

Das mit dem Kopieren/Sharen über die "scratch partition" war nur meine Annahme, auch weil die eben update_tmp benannt ist und auf beiden Cores gemountet wird (iirc, den ARM-Teil schaue ich das jetzt nicht auch noch an - kann man leicht selbst vergleichen, ob die E16-... übereinstimmen oder nicht). Fun-Fact am Rande: Eine Zeitlang wurden diese Partitionen sogar zwischen den Cores über NFS geteilt - mittlerweile ist das aber wohl (zumindest bei den Puma7-Geräten) auch wieder Geschichte und wie das konkret in welcher Abfolge jetzt implementiert ist, muß man eben erst einmal erkunden, solange es nicht schon eine Beschreibung dazu gibt, die mir entgangen wäre.
 
Mal schauen, ob sich @fesc wg. der "Referenz" hier meldet
Die referenz ist eigentlich das: https://bitbucket.org/fesc2000/uimg-tool
welches wiederume identisch mit den sourcen im bitbucket ffritz repo ist. Da müsste ich es eigentlich mal rausschmeissen. Das github repo ist nicht up-to-date, am besten ich loesche es oder markiere es als obsolet.

Die unkown parameter waren nur timestamps die eigentlich funktional keinen Einfluss haben sollten.

Generell kann ich mich an einen Fall erinnern bei dem burnuimg nicht funktioniert hat, und bei dem ein reboot das behoben hat. Ist aber schon länger her, und ich weiss nicht ob es das gleiche Fehlerbild war.

Was sagt denn z.B. "uimg -i firmware-file" (aus obigen repo gebaut).
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
246,247
Beiträge
2,248,790
Mitglieder
373,831
Neuestes Mitglied
v4l3r10
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.