Über EVA sollte sich - wenn Du ein System installieren konntest - auch das andere auf die Box bringen lassen. Oder hast Du tatsächlich bisher immer nur ein einzelnes System auf der Box benutzt?
Irgendwo gibt es doch für die Puma7-Boxen auch eine Auflistung/Anleitung, welcher MTD-Name im Bootloader für welche Partition steht - ja, das war iirc sogar das Modell, wo diese Namen dann Sonderzeichen enthalten, weil einfach die ASCII-Tabelle "durchlaufen" wird bei den Nummern und dann nach der 9 die ersten Sonderzeichen folgen. Zwar weiß ich auch nicht (ohne es erst zu suchen und das schaffst Du sicherlich alleine), wo das zu finden war - vermutlich wird sogar
push-firmware aus Freetz-NG das irgendwo in Form von Code enthalten. Ich kann mich nur an irgendeine Stelle im 6591-Thread erinnern, wo es um das korrekte "Escapen" dieser Namen ging, wenn man einen "echten" FTP-Client benutzt.
Das mit der
E16-filesystem-update war auch nur der Wink mit dem Zaunfeld, wo man das alles ganz exakt selbst nachlesen könnte (und sollte) - ich habe nicht immer Bock darauf, jeden Tipp, wo's eigentlich nur um ein Prinzip geht, durch eigenes "Nachsehen" in den Daten zu verifizieren (und dann stimmt schon mal ein Datei- oder Pfadname nicht, wie es bei
/var/tmp/remote der Fall war oben) oder gar einen Link heraus zu suchen oder Teile aus solchen Dateien zu "zitieren" und/oder zu zeigen und deshalb schreibe ich dann ein "abschwächendes" "iirc" oder "m.W." o.ä. dazu.
Aber alles, was in den originalen AVM-Images enthalten ist (egal, ob auf dem ATOM- oder dem ARM-Core), kann ich mir (wie jeder andere Interessent auch) schon selbst ansehen (wenn ich es auch will), wie ein paar CODE-Kästen oben ja belegen. Es gibt auch keinen offensichtlichen Grund, warum sich die Datei in Deinem Image von der bei AVM vorhandenen unterscheiden sollte und es gibt (oben auch angemerkt) sogar zwei dieser
E16-filesystem-update - auf jedem System jeweils eine.
Da dieses "invalid sector" offenbar ja nun doch nichts mit dem Aufbau der
uimg-Datei zu tun hat, ist ja auch das Tool dafür als Ursache gleich wieder raus aus dem Rennen. Das Image enthält ja nur fünf Parts:
Rich (BBCode):
vidar:/home/FritzBox/FB6591 $ uimg -i firmware-update.uimg
Identifier: Intel_Unified_Image
Vermagic: 0x33524556 (VER3)
Timestamp (dd.mm.yyyy hh:mm:ss): 01.06.2021 09:58:12
partition_02_ATOM_KERNEL.bin size=9437184 crc=0x24023fba
partition_03_ATOM_ROOTFS.bin size=28721152 crc=0x09c1d075
partition_08_ARM_KERNEL.bin size=2766336 crc=0xbc73e6e8
partition_09_ARM_ROOTFS.bin size=15876096 crc=0x0762a110
partition_10_GWFS.bin size=450560 crc=0x23397f12
vidar:/home/FritzBox/FB6591 $
und die reichen nicht aus, um damit auch zwei Systeme (also die zwei Partition-"Sets", die für die abwechselnde Benutzung beim Update üblicherweise verwendet werden) zu füllen.
Und da auch nicht klar ist, welche Box beim Update gerade welches dieser zwei Systeme aktiv hat (also ob
linux_fs_start nun
0 oder
1 ist), kann der Wert auch nicht aus dem AVM-Image (oder dem "nachgebauten" von Freetz-NG) kommen. Daher MUSS der irgendwo auf der Box ermittelt werden - bleibt nur die Frage, wie dabei noch ein Fehler auftreten soll.
Was in dem Zusammenhang auch noch spannend wäre, ist tatsächlich mal ein Update über das GUI mit einer originalen AVM-Datei (man kann dann ja über
linux_fs_start auch wieder auf den Stand vor dem Update zurück nach dem nächsten Start, das sollte m.W. zuverlässig funktionieren, s. 6591-Thread) ... klappt das, wäre die Frage, was dabei dann anders sein soll, als beim selbst zusammengeklöppelten
uimg aus Freetz-NG.
So rein von der Logik her, sollte das eben keine Rolle spielen dürfen, denn ein Zusammenhang zwischen
uimg-Datei und diesem "sector" (wenn die Annahme, daß das die Intel-Entsprechung für
linux_fs_start ist, auch stimmt) ist eben nicht zu erwarten ... Begründung steht oben.
Was ich mir noch vorstellen KÖNNTE (ohne das testen zu können), wäre eine Steuerung der Auswahl dieses "sectors" vom ATOM-Core aus, weil es wieder einen Unterschied macht, ob die Box ein
uimg im "Update-Modus" (dann in die Partitionen für das inaktive System mit Umschaltung nach erfolgreicher Installation) oder im "Recovery-Modus" (dann wieder direkt in die Partitionen für das aktive System, weil vermutlich auch dabei dann das System nicht aus den eMMC-Partitionen gestartet wurde und die damit auch überschrieben werden können) ausführen soll. Dann würde eine solche Festlegung vom ATOM-Core aus wieder Sinn ergeben und dieser Schritt könnte fehlen, wenn man das
burnuimg "von Hand" aufruft.
Denn es ist nicht automatisch gesagt, daß der Fehler beim Update-Versuch durch
firmwarecfg (da steht ja etwas von einem Status-Code von 5120 im Protokoll) auch derselbe ist, der beim "händischen Aufruf" von
burnuimg aufgetreten ist - das ist bisher nur eine Vermutung. Dazu könnte/müßte man noch einmal den Exit-Code vom
burnuimg anschauen - wobei da der Wertebereich eigentlich nur von 0 bis 255 (bzw. -1) geht, weil da eigentlich nur ein 8-Bit-Integer verwendet wird. Vermutlich wird dieser Status-Code dann doch irgendwo anders seine Quelle haben oder er ist eine Kombination aus zwei einzelnen 8-Bit-Werten - die hexadezimale Darstellung von 5120 (0x1400) würde das zumindest als Theorie hergeben. Daher wäre es nützlich, den Wert am Ende von
burnuimg zu kennen - und spätestens, wenn man den
burnuimg-Aufruf dann doch über einen Wrapper laufen lassen wollte, hätte man (solange man das Original dann nicht über
exec startet) diesen Return-Code auch automatisch, wenn man ihn nur irgendwo protokolliert.
Es gibt auch noch andere Optionen, wie man sich weiter "herantasten" kann - nur wird das immer komplexer und man braucht auch immer mehr Linux-Kenntnisse. Da bin ich nach Deinen eigenen Ausführungen nicht mehr ganz so sicher, daß das die richtige Aufgabe für Dich wäre - denn ich kann (und will) nicht alles bis ins Detail erklären, sondern eher "Prinzipien" aufzeigen und Tipps/Hilfestellungen geben.
Von
strace habe ich schon geschrieben und wie man auch ein CGI-Binary (und das ist
firmwarecfg, wenn man es für ein Firmware-Update aufruft) direkt von der Shell aus testen kann (da müssen dann bestimmte Werte beim Aufruf im (Shell-)Environment vorhanden sein und ein passender Datenstrom auf STDIN bereitgestellt werden - das ist der Inhalt des POST-Requests beim CGI-Call), ist keine "rocket science" und wurde von mir u.a. für die direkte Aufzeichnung von Netzwerk-Mitschnitten auf dem USB-Speicher der FRITZ!Box auch schon mal "gezeigt" in irgendeinem Thread hier.
Mit dieser Kombination kann man sich dann auch ansehen, was da beim
firmwarecfg noch so alles passiert (zumindest alles, was in einen Syscall mündet), bevor von dort dann das
burnuimg aufgerufen wird - das wäre der bzw. ein Ansatz, wenn man die Theorie, daß das irgendwie "außerhalb" des
burnuimg-Aufrufs festgelegt wird (und daher bei Deinem Aufruf nicht dabei war), überprüfen wollte. Außerdem kann man natürlich mit einem Shell-Skript als Wrapper um
/sbin/burnuimg auch dafür sorgen, daß die Option
-s, die wohl von
firmwarecfg hinzugefügt wird beim Aufruf, wieder ausgefiltert wird und man kann auch die Ausgaben vom "echten" Aufruf von
burnuimg dann wieder (ggf. auch nur zusätzlich mit
tee) in Dateien umleiten, wo man sie genauer ansehen kann (und vor allem auch für genau den Aufruf, der von
firmwarecfg aus erfolgt).
Wie gesagt - das wird alles zunehmend komplexer, weil es (nach dem, was
@fesc oben geschrieben hat) bisher offenbar noch "unentdecktes Land" (Terra incognita) ist, wie das neue AVM-Update bei den Puma7-Boxen genau arbeitet. Daher gibt es da eben keine "fertigen" Lösungen und man muß sich Stück für Stück weiter herantasten, was natürlich mit passendem Grundlagenwissen für Linux auch deutlich leichter ist, als wenn man nur "Anweisungen" ausführt.
Daher mußt Du selbst wissen, wieviel Energie Du da noch hineinstecken willst (am Ende winkt beim Erfolg halt auch für andere die Option, signierte Images ohne den Weg über EVA oder das UEFI-BIOS installieren zu können) - ansonsten mußt Du dann damit leben, daß wohl doch nur der Weg über den Bootloader bleibt bei der Installation.
Wobei man den auch so gestalten kann, daß man dazu eine Box - solange sie über ein LAN-Kabel irgendwo angebunden ist - nicht erst ausbauen und direkt an einen PC anschließen muß ... auch das ist keine Raketen-Wissenschaft, man braucht nur die passenden Tools und afaik, ist das bei den Puma7-Modellen auch nichts anderes als bei anderen DOCSIS-Modellen von AVM, wenn's um den Kontakt mit EVA geht und die Anleitung dazu (yourfritz.de/desc-docsis), sollte auch bei der 6591 funktionieren - zumindest der Teil mit der Suche nach der richtigen Box.
Ob das mit
push_firmware auch noch geht, wenn man die Box bereits im FTP-Modus vorfindet, weiß ich nicht - an dem Tool habe ich einige Kritikpunkte (gerade im Hinblick auf das Suchen und Finden der richtigen Box), die irgendwo hier auch zu finden sind in einem Thread. Aber man kann den Teil, der in
push-firmware bei den Puma7-Modellen abläuft (
https://github.com/Freetz-NG/freetz...78d9460b657998d5683e/tools/push_firmware#L260), ja auch mit anderen Tools ausführen - das ist ja nichts anderes, als das aufeinander folgende Beschreiben der passenden MTD-Partitions.
Dann hängt man noch eine WLAN-Steckdose (~ 10 EUR) mit TASMOTA-Firmware an das Netzteil der FRITZ!Box (ggf. auch mit einer Routine, die auf Kommando den Strom ab- und nach 10-15 Sekunden von selbst wieder einschaltet - so eine "Treppenlicht-Routine" (hier halt dann "umgekehrt", weil die "Aus"-Zeit gesteuert/begrenzt wird) habe ich irgendwo im Tasmota-Thread mal gezeigt) und dann kann man die auf Kommando auch so neu starten (selbst wenn das WLAN über die Box selbst laufen sollte, wobei TASMOTA ja auch einen eigenen AP anbieten könnte), daß danach EVA tatsächlich erreichbar wird (das braucht neuerdings bei manchen Modellen ja ein Power-On-Reset).
Man muß dann nur noch irgendwie an eine Verbindung kommen können, die am Kabel bei der FRITZ!Box ankommt (also keinen Laptop per WLAN o.ä., solange es keinen zweiten AP gibt, der dann wieder auf das Kabel geht). Das mache ich (nunmehr seit Jahren) bei meinen Test-Boxen so in der Software-Entwicklung/-Analyse ... ich würde verrückt werden, wenn ich da jedesmal eine "Spezialverkabelung" herstellen oder irgendwelche Netzteile oder auch nur Rundstecker an der Box ziehen und wieder einstecken müßte. Wenn die Box hinter dem Schrank wirklich gar kein Kabel gesteckt hat, muß man eben für solche Fälle dann doch noch eines einstecken und liegen lassen. Das spart zumindest das Abrücken des Schranks und irgendwelche "Umzüge" mit der FRITZ!Box, solange man einen Rechner hat, mit dem man zur Box marschieren kann, ansonsten braucht man eben ein sehr, sehr langes Kabel, je nach Architektur ... und das kann man danach ja auch wieder "einrollen".
EDIT: OK, den Test mit dem Update über das AVM-GUI und dem Syslog-Eintrag für "invalid sector -1" hatte ich bisher nicht gesehen (da stand der Thread zu lange offen in einem Browser-Tab herum und nachträgliche Bearbeitungen werden dann nicht angezeigt - nur neue Beiträge) - damit tritt das offenbar auch dann auf, wenn man's über
firmwarecfg aufruft/aufrufen läßt.
Die weiteren Überlegungen dazu, ob es dann einen Unterschied zwischen dem automatischen und dem manuellen Aufruf von
burnuimg geben könnte, sind damit hinfällig - nur nicht die Frage, warum da dann offensichtlich ein falscher Wert "berechnet" oder angenommen/übergeben wird und wo diese Auswahl letztlich erfolgt. Da muß man dann wohl wirklich die AVM-Programme über Wrapper starten (da kann man ja auch nicht nur Ein-/Ausgaben umleiten und Parameter ändern, sondern auch noch ein
strace verwenden, wenn man eines hat) und sich genauer ansehen, wer da was macht.
Kandidat dafür wäre primär das
firmwarecfg (wobei das dann auch ein CGI-Environment braucht an dieser Stelle und das CGI verwendet bei AVM nur ein sehr ausgedünntes Shell-Environment, wo PATH u.ä. auch mal nicht gesetzt sein kann - das macht das Dazwischengrätschen etwas schwerer und so würde ich das immer "von Hand" starten und nicht über das GUI/den
ctlmgr) auf dem ATOM-Core oder man schaut noch einmal genau nach, was bei einem Update-Versuch über TR-064 passiert - der wird (vermutlich) an anderer Stelle ausgelöst und nicht unbedingt über
firmwarecfg laufen, sondern eher über
tr069fwupdate (ohne
packet). Wenn "sector" doch vom ATOM-Core festgelegt wird, wäre das zumindest mal ein anderes Binary auf diesem System und nicht mehr
firmwarecfg (sofern alle Prämissen auch stimmen) .. .und das könnte man auch wieder leichter mit einem Protokoll-Wrapper versehen, weil's nicht über CGI aufgerufen wird.
