[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

pyrochroa schrieb:

Komischerweise verschwinden dabei sowohl die Einträge "Sicherung" als auch "Update" aus dem Navigationsmemü.

Zum Vergrößern anklicken....

Das ist insofern besonders komisch, als daß ja an dieser Stelle eigentlich ein Neustart erfolgen sollte und die Seite "Warte auf Neustart ..." meines Wissens kein Menü enthält.

Entweder es geht etwas schief beim "Umschalten" des Systems (also beim Aufruf von "guibootmanager switch_to") und das Problem liegt in meinem Skript oder es ist ein generelles Problem beim Neustart der Box. Andererseits ist das i.d.R. ein gesonderter Frame, in dem das Menü angezeigt wird und das deutet für mich eher auf ein anderes Problem im "ctlmgr" (der macht ja auch den Webserver für die Box) hin.

Ist denn der beim Klicken auf "Neustart" erzeugte HTML-Code auch so fehlerhaft, daß die Darstellung des Menüs dem Inhalt der HTML-Datei entspricht?

Eigentlich wäre dann - nach meinem Verständnis, aber eine 7490 hat eben zwei Prozessorkerne und (potentiell) auch im "ctlmgr" Multithreading, falls AVM das tatsächlich nutzen sollte - die "Seite" reboot.lua noch gar nicht an der Reihe.

Einfacher Test wäre es, mit folgender Kommandofolge die Funktion des "guibootmanager" erst einmal zu testen;
Je nach angezeigtem Wert dann mit
auf das andere System umschalten (da passiert erst mal noch nichts, solange nichts einen Neustart auslöst), das aktive System wird entweder durch eine "0" oder eine "1" ausgewiesen und das alternative System ist dann jeweils das andere. Den Erfolg der Umschaltung kann man dann wieder mit dem "grep"-Kommando überprüfen. Am Ende dann am besten wieder auf die ursprüngliche Einstellung zurücksetzen.

Wenn dann die prinzipielle Funktion des Skripts geklärt ist, kann es (wenn die Ursache nicht an einer vollkommen anderen Stelle zu suchen ist) eigentlich nur noch ein Problem mit dem zusätzlichen Lua-Code in reboot.lua geben. Hier könnte AVM eigentlich nur noch die Möglichkeit zum Aufruf von "os.execute" ausgebaut haben, das wäre dann eine "direkte Gegenmaßnahme" und das halte ich eigentlich für unwahrscheinlich.

Ich kann leider gerade selbst die 06.24 nicht noch einmal testen, da meine 7490 anderweitig beschäftigt ist und der derzeitige Upload wohl noch mind. 12 Stunden dauern wird.

pyrochroa schrieb:

Nee, das sieht nicht gut aus:

Zum Vergrößern anklicken....

Irgendwas scheint da nicht so zu wollen, wie es sein sollte ... ich bin leider im Moment etwas gehandicapt - mußt Du also bei Dir selbst checken.

EDIT:
Sorry, mein Fehler ... der korrekte Aufruf ist "guibootmanager switch_to X", wobei X entweder "running" oder "alternative" sein muß.

Über die Variable "linux_fs_start" im Urlader-Environment (manuell) oder über das kommandozeilenbasierte Tool "bootmanager" in einer Telnet-Session sollte das problemlos klappen.

pyrochroa schrieb:

du hast nicht das Problem mit dem leeren GUI Bootmanager

Zum Vergrößern anklicken....

Hast Du denn die Ursache gefunden? Da stand ja noch eine Antwort, ob der erzeugte HTML-Code (der ja offenbar syntaktisch richtig war) am Ende auch an den Browser übermittelt wird oder nicht, aus, genauso wíe die Frage, warum das Menü sich plötzlich änderte beim Klicken auf "Neu starten" und trotzdem kein Neustart erfolgte. Das habe/hatte ich noch nicht von anderer Seite gehört.

Wenn der HTML-Code unterwegs verloren geht, machen die Skripte wohl etwas falsch ... ansonsten kann es ja auch ein Darstellungsproblem im Browser sein. Die entscheidende Frage ist und bleibt erst einmal der Quelltext der "reboot.lua"-Seite im Browser (vor und nach der Auswahl von "Neu starten"), von dort muß man dann rückwärts suchen. Auch der Netzwerk-Monitor eines Firefox kann da hilfreich sein, da einiges dort u.U. als Ajax-Request asynchron läuft ...

Die Ursache für die fehlende Modifikation der Restart-Seite in der AVM-GUI ist gefunden, wird mit der nächsten Version des Pakets auf dem Server auch korrigiert werden.

AVM hat in den Labor-Versionen nach der 06.24 in der originalen Datei ein Statement entfernt, an dem sich das automatische Editieren der Datei orientierte.

Warum das dann bei pyrochroa aber mit 06.24 nicht funktionieren wollte, ist mir immer noch ein Rätsel ... was soll's.

Da ich - wenn es bei AVM wieder halbwegs stabile Labor-Versionen gibt und die nicht jede Woche wechseln - auch mal wieder eine Labor-Version auf verschiedenen Boxen testen wollte und dabei die Änderungen im System brauchte, habe ich kurzerhand das Skript etwas erweitert.

Es ist jetzt nicht mehr zwingend notwendig, die zu installierende Version bereits als aktives System zu betreiben (also z.B. die 06.24 zu installieren und dann erst zu modifizieren). Durch Aufruf mit dem Parameter "update" wird das Skript nun veranlaßt, sich eine neuere Version vom AVM-FTP-Server zu laden, wenn es eine solche finden kann. Ansonsten wird die Modifikation abgebrochen.

Das bringt aber für Labor-Versionen u.ä. noch nicht den gewünschten Erfolg, deshalb ist zusätzlich auch noch die Angabe eines Dateinamens hinter dem Update-Parameter möglich. Dann wird diese Datei als Firmware-Image für die Änderungen interpretiert, es muß eine komplette "image"-Datei (wie von AVM) sein, also ein TAR-File mit den Dateien "kernel.image" und "filesystem.image" unter dem Verzeichnis "var/tmp" sein.

Auf diesem Weg lassen sich dann auch ältere Versionen oder Labor-Versionen installieren, eine Versionsprüfung findet dann absichtlich nicht statt. Jeder ist also selbst dafür zuständig, die Kompatibilität von Einstellungen zu prüfen und ggf. die Box auf Werkseinstellungen zurückzusetzen, wenn er ein Downgrade ausführt (spätestens bei ersten Merkwürdigkeiten).

Beim Laden eines Updates vom AVM-Server wird die Versionsnummer auf streng größer geprüft, eine Installation einer Labor-Version mit identischer Minor-Number ist über "update" ohne Dateinamen also auch nicht möglich.

Eine nach "update" angegebene Firmware-Datei muß lokal auf der Box vorhanden sein (keine URL-Angabe), ggf. also zuerst manuell vom AVM-Server geladen werden (und bei Labor-Versionen auch erst aus dem üblichen ZIP-File extrahiert werden).

Bei Labor-Versionen wird es natürlich zunehmend unwahrscheinlicher, daß die vorhandenen Modscripts ohne Änderungen funktionieren, ein Beispiel ist das o.a. Modifizieren der Restart-Seite, was eine Anpassung benötigte. Da das auch schon bei der ersten Labor-Version 06.25-29805 der Fall war, hatte ich bei pyrochroa fast den Verdacht, daß es gar keine 06.24 war, wie in #59 beschrieben. Aber das kann eben immer passieren ... also bei Laborversionen sollte schon jeder selbst prüfen bzw. bei den Modscripts mit pre- und postcheck-Tests sich die Ergebnisse richtig ansehen.

Aber damit wird aus einem einfachen Update eben nicht mehr automatisch ein größerer Aufwand ... man kann anstelle des Updates per GUI auch mit "modfs" aktualisieren und hat dann sogar (weil das neue System dann das Umschalten in der reboot.lua enthalten könnte - wenn man's installieren läßt und es funktioniert) die Chance, auf das letzte System auszuweichen, wenn einem das neue nicht gefällt.

Die neue Version wird bis morgen früh auch auf dem Server ankommen, ich muß bloß noch die deutschen Texte nachziehen, bevor ich den Upload mache.
Die neue Version liegt anstelle der alten auf dem Server.

Erst einmal kannst Du mit dem "bootmanager"-Skript prüfen, was derzeit in der Box installiert ist. Abhängig vom derzeitigen Stand kann man dann mit einzelnen Kommandos einen Stand herbeiführen, der für "modfs" taugt.

Abgesehen davon, nach den letzten Änderungen kann ja auch ein "update" direkt mit dem Skript ausgeführt werden, dabei wird überhaupt nicht nach der alten Version in der Partition geschaut.

Nur die "linux_fs_start"-Variable sollte schon existieren, ob das Skript auch damit klar käme, wenn es diese noch nicht gibt, weiß ich aus dem Stand gerade nicht ... sollte das nicht der Fall sein, müßte ich da entsprechend ergänzen.

Ansonsten könnte es bei der internationalen Version sein, daß einige der Skripte zum Modifizieren von Dateien ins Leere gehen, wenn sich dort etwas am Aufbau von Dateien ggü. der deutschen Version geändert hat. Also ordentlich die Ausgaben lesen und - das wäre die beste Lösung - bei der angebotenen Pause einfach die Dateien noch einmal überprüfen (notfalls rauskopieren), die geändert sein sollten.

Das Skript ist eben nur ein "Framework" ... was man konkret ändert/ändern läßt, ist in den "modscripts" hinterlegt bzw. das Ergebnis manueller Änderungen, bevor das Filesystem wieder gepackt wird. Das Prinzip funktioniert jedenfalls auch bei der internationalen Version ... selbst probiert habe ich es (in der aktuellen Version des Skripts) nicht erneut; ich hatte es nur (vor längerer Zeit, als die 06.20 int. erschien) mal auf eine "umetikettierte" deutsche Box losgelassen.

Ich habe mal ein neues "modscript" dem Archiv auf dem Server hinzugefügt, mit dem man den Telnet-Daemon in der Labor- (oder Beta-) Version 06.25-30584 wieder aktivieren kann, wenn man das Update auf diese Version über "modfs" ausführen läßt.

As I wrote in the other thread, I haven't got enough information yet to make it running on a 3490 ... I wrote, it could be an easier way, but the first user on a 3490 has to be a pioneer and must modify the script appropriately or provide the necessary information to me.

To avoid additional round-trips of questions and answers I'd like to get the "support data" of such a box ... if it's possible without any user data included.

The best way to generate such a file would be a factory reset, followed by a minimal configuration (dummy user account and password) and subsequently a call to "http://fritz.box/support.lua" to generate the whole file. If you would like to provide such a file, you'll get an email address to send it to.

If you export the current settings prior to the factory reset, you're able to restore it after generating the support data. The reset is only necessary to assure, that the file doesn't contain any confidential data (beside the MAC address of the device itself).

Within the support file I can find the needed informations ... my first step would be an examinatio, if it's possible at all. Some important points are the boot loader, the "urlader environment settings" (linux_fs_start) and the layout of the flash. If it could probably work, I'll modify the script to contain the new hardware version to pass the check and after that I would send it to you (by email). Then you had to try it first up to the point, where the new image is built up and flashed, but for the first attempt I would suggest, that you change the "system selector" back to the current system and provide me the changed file system and the original one for examination, if the changes are looking as desired. If this is finally the case, you have to try a reboot of your device with the modified firmware. If something wents wrong, there are two options to switch back to the previous system ... first is to switch the content of "linux_fs_start" again (with FTP access to the bootloader or a tool called 'ruKernelTool') and the second one would be the use of a recovery program, if you got one.

If you're prepared to do this process together with me (the support for 3370 was introduced together with user 'lebedev' using only an IRC chat, but he was able to modify the script himself), you're welcome. If you'd like to try it with my IRC support yourself, that's even an option.