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

[PeterPawn]

Dann wage ich mal die Behauptung, daß sowohl das aktive als auch das inaktive System nur ein einziges Branding unterstützen (nämlich "avme"), dann gibt es auch keine Möglichkeit (eben auch keine Notwendigkeit), das Branding irgendwie umzustellen ... ganz im Gegenteil, diese Erweiterung um die Kontrolle des Brandings soll ja gerade sicherstellen, daß beim Systemwechsel auch ein Branding aktiviert wird, das vom beim nächsten Start zu ladenden System auch unterstützt wird. Dann enthalten sicherlich beide "span"-Elemente genau denselben Text und man sieht die Umschaltung zwischen ihnen nur im HTML-DOM mit den Developer-Tools.

Wie das in den verschiedenen möglichen Zuständen gehandhabt wird (also welcher HTML-Code erzeugt wird), kann man sich in der Datei /usr/bin/guibootmanager ansehen und das wäre auch die Stelle, wo man das irgendwie ändern könnte ... solange man bei den zwei HTML-"span"-Elementen für die (wechselnde) Anzeige für das per Radiobutton selektierte System bleibt, sollte sich am Inhalt der /usr/www/$OEM/system/reboot.lua nichts ändern müssen (unter 06.50+ bzw. 06.36 als Laborzweig).

BTW ... ich habe oben bei der Erläuterung der Erweiterung des BootManagers glatt noch vergessen zu erwähnen, daß bei v0.1 nur die Lua-Datei für das beim Modifizieren (also bei modfs-Ausführung) aktive Branding bearbeitet wurde. Da das dann in direktem Widerspruch zu der Wahlmöglichkeit bei mehreren Brandings beim Neustart stehen würde, werden von modfs die reboot.lua-Dateien in allen Brandings geändert bei der Verwendung von v0.2.

 

[coco722]

Frage zu einem Test-Versuch: Im aktiven System im mtd0/mtd1 (modfs auf intl avme 6.36) wird ein neues root image mit "modfs update" verarbeitet (und zwar eine fw avm 6.50), damit das dann auf das inaktive System mtd2/mtd3 platziert wird. Leider kommt die Fehlermeldung:
verwendenden Brandings zum 'Neustart'-Tab des Webinterfaces
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
grep: /var/media/ftp/1455533414/squashfs-root/usr/www/avme/system/reboot.lua: No such file or directory
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... Fehler (1)
grep: /var/media/ftp/1455533414/squashfs-root/usr/www/avme/system/reboot.lua: No such file or directory
Die Modifikation war nicht erfolgreich.

Die Modifikation 'enable system and branding selection from GUI (v0.2)' wurde angewendet, Fehlercode = 1.

Wie liesse sich das korrigieren (sofern möglich...offensichtlich wird im pfad .../avme/... gesucht, was heissen müsste (wegen einem de image) .../avm/...) ?


Es wurde kein reboot in der konsole eingegeben, nach Ablauf des modfs scripts. Im Web GUI wurde ein Neustart eingegeben, wieder auf das aktuelle System. Danach ist im Web GUI tatsächlich das inaktive System mit Branding-Auswahl da - siehe Anhang:


Wow, hat prima geklappt (trotz der einen Fehlermeldung wg. dem GUI 0.2):
Nun sind es 2 Systeme (einmal intl. avme 06.36 und noch de avm 06.50), funktionieren beide einwandfrei, über Web GUI Neustart lässt sich zw. beiden (durchaus unterschiedlichen) Systemen nunmehr hin und her wechseln - siehe Anhang. Alles Prima !

 

[coco722]

Leider ist im System (mtd2/mtd3 mit de avm 06.50) die Shell-inA-Box (auf Port 8010) nicht mehr erreichbar. Telnetd lässt sich problemlos über Wahlhilfe aktivieren und ist zugänglich. Um auf diesem System shellinabox wieder verfügbar zu machen, soll das pseudo-update modfs-Starter sgfs4 neu eingespielt werden oder gibt es da einen besseren Weg ?


Im System de avm 6.50 auf mts2/mtd3 wurde die injekt-shellinabox...sqfs4.tar als update aufgespielt,
nun ist hier auch shellinabix unter Port 8010 vorhanden.

BEGEISTERT, Dank @PeterPawn.
2 Systeme (International avme 06.36 beta, Deutsch avm 06.50), beide mit telnetd aktivierbar/deaktivierbar über Wahlhilfe/Telefonbucheintrag, ShellinABox unter 8010 nunmehr auf beiden Systemen vorhanden, Wechsel zwischen Systemen geht EINWANDFREI. Alles bestens !!!




Frage mich nunmehr, was passiert, wenn man aus einem System heraus im GUI die Werkeinstellungen wieder ladet. Wird dann nur das aktive System auf Werkeinstellungen zurückgesetzt (und auf die richtige fw Version) ? Bleibt das andere System intakt (wahrscheinlich wär dann wohl ein Wechsel im GUI nicht mehr vorhanden, könnt ich mir vorstellen) ?

 

[PeterPawn]

Wird dann nur das aktive System auf Werkeinstellungen zurückgesetzt (und auf die richtige fw Version) ?

Es gibt bei AVM keine gesonderten Einstellungen pro System, die Einstellungen werden (an gänzlich anderer Stelle als die Firmware-Versionen) für die gesamte Box verwaltet.

Man müßte sich also eine entsprechende Sicherung pro System selbst basteln, das habe ich (für die Kommandozeile) mal vor Urzeiten im "bootmanager" realisiert und ab und an setze ich es heute selbst noch ein, wenn ich sehr unterschiedliche Versionen in einer einzigen Box verwende oder wenn ich nicht will, daß die Anrufliste oder das Telefonbuch beim ständigen Sichern und Wiederherstellen von Einstellungen in Mitleidenschaft gezogen werden.

EDIT: Irgendwie werde ich aus der Anzeige von "guibootmanager" in #444 nicht so richtig schlau, die Feststellungen zum Branding sind doch deutlich falsch ... solange die 06.50 ausgewählt ist (das ist ja wohl die deutsche Version), sollte da doch stehen:

Das oben ausgewählte System unterstützt mehrere Firmware-Versionen (Brandings), im Moment ist "aktives Branding, vermutlich [I]avm[/I]" eingestellt.
Beim nächsten Start wird folgender Wert gesetzt und bis zur nächsten Änderung verwendet: [I]hier kommt die Select-Box[/I]

und wenn das inaktive System ausgewählt ist (die 06.36 ist sicherlich die internationale Labor-Version), dann sollte dort stehen:

Das oben ausgewählte System unterstützt nur das Branding "avme", im Moment ist jedoch "[I]aktuelles Branding (das kann ja nur avm oder 1und1 sein)[/I]" eingestellt.
Bei der Umschaltung des zu verwendenden Systems wird daher auch gleichzeitig das Branding auf "avme" geändert.

Da stimmt irgendetwas noch nicht richtig ... selbst wenn man das zu bootende System auf anderem Wege umschaltet, sollte die Seite beim Aufruf den richtigen Radiobutton vorauswählen und auch den richtigen "span" anzeigen und den anderen verstecken. Da muß ich wohl noch einmal einen Blick drauf werfen ...

EDIT2:
Ja, die Initialisierung der Sichtbarkeit der "span"-Elemente für das aktive und das inaktive System ist vertauscht ... das habe ich bei der Änderung auf das neue Design ja erst nachträglich eingebaut/einbauen müssen und das fällt nur dann so richtig auf (jedenfalls vor dem ersten Klick auf einen Radio-Button, weil es anschließend wieder stimmt), wenn man auch wirklich zwei sehr unterschiedliche Systeme in der Box verwendet. Das ändere ich gleich noch, die Versionsnummer lasse ich aber unverändert - das ist (da es sich ja um ein "modscipt" als Beispiel handelt und nicht um "modfs" selbst) keinen neuen Schritt wert.

 

[coco722]

Nur wenn System avme 06.36 beta auf mtd0/mtd1 aktiv ist, dann ist beim GUI screen Neustart die Dropbox vorhanden (beim anderen System sieht's halt anderes aus...aber Hauptsache es funktioniert einwandfrei mit dem Wechsel zw. den Systemen).
Stell mir auch vor, wenn man im 2. System ist auf mtd2/mtd3 (mit avm 06.50) braucht es die Dropbox gar nicht, weil das System kann ja nur noch zum anderen Wechseln (und da steht's schon fest, dass branding avme sein muss)...

 

[PeterPawn]

Ich habe die neue Version eingecheckt und auf dem Server auch geändert ... jetzt sollte das auch von Beginn an stimmen. Vor dem nächsten Update mit "modfs" sollte man also noch einmal einen Download machen, wenn man sich eine lokale Version hingelegt hat. Die 0.3.2 bleibt jetzt erst einmal so stehen, ab jetzt geht es mit einem neuen Branch 0.3.3 weiter, der in erster Linie einige Änderungen am AVM-GUI hinzufügen wird.

 

[KingTutt]

---

-

• die Änderung zum Umschalten zwischen den Systemen per GUI (guibootmanager) ist jetzt in zwei Versionen enthalten (einmal als gui_boot_manager_v0.1 mit der bisherigen Version und einmal als ..._v0.2 mit der neuen), wobei nur die neuere als "optional" angeboten wird
• diese neue Version funktioniert (vermutlich) nur mit dem neuen "responsive design" der AVM-Firmware, für eine ältere FRITZ!OS-Version sollte man dann lieber mit "chmod ug-x modscripts/gui_boot_manager*" die neue (bzw. beide) Version(en) deaktivieren und mit "chmod ug+x modscripts/gui_boot_manager_v0.1" die alte wieder "optional" aktivieren
• das erweiterte Shell-Skript dahinter kümmert sich jetzt bei Bedarf auch darum, daß das Branding bei einem Wechsel der zu verwendenden System-Version so angepaßt wird/angepaßt werden kann, daß es auch einen Wert hat, der in dem anderen System überhaupt enthalten ist ... wer also zwischen einer deutschen Version (meist ja mit "avm" und "1und" im Dateisystem) und einer internationalen Version (nur Branding "avme") umschalten will, kann jetzt gleich bei der Umschaltung das Branding passend setzen lassen
  Anhang anzeigen 85629

Was müsste man eigentlich machen, um den GUI bootmanager ist eine custom FW zu integrieren? Könnte man auf einem Linux System (nicht auf der Fritz!Box selbst) den 2ten Teil des Scripts benutzen um eine ausgepackte Firmware zu patchen oder läuft das ganze nur in einer busybox Umgebung?

 

[PeterPawn]

@KingTutt:
Mit ein wenig Bastelarbeit (in erster Linie wahrscheinlich das Simulieren einer passenden Umgebung im procfs, da wird das Urlader-Environment und die MTD-Tabelle gebraucht) sollte sogar das komplette "modfs" auf einem x86-Linux laufen können.

Die Alternative ist halt der Aufruf eines "modscripts" von Hand ... solange die vier Parameter stimmen und die benötigten Kommandos existieren (notfalls nimmt man eine x86-Busybox dafür her), sollte das auch unter jeder anderen Shell (bzw. eher unter bash als unter csh oder ksh) funktionieren ... mir fällt jetzt nicht ein, was da außer "cat" und "sed" verwendet werden sollte - solange das angegebene Verzeichnis ein ausgepacktes FRITZ!OS-Root-FS ist, braucht das "gui_boot_manager_v0.2" nicht einmal mehr (wie das vorhergehende) einen Zugriff auf das procfs, weil die Brandings nicht mehr aus $OEM (war nur ein einzelnes vorher, damit das richtige "reboot.lua"-File geändert wurde, wenn es mehrere gab), sondern aus dem Dateisystem gelesen werden.

Im Prinzip gilt das wieder für jedes "modscript", solange das nicht (z.B. bei "precheck" oder "postcheck") auf irgendwelche FRITZ!Box-Spezialitäten zugreifen will. Eine absichtliche Prüfung, ob es auch auf einer FRITZ!Box läuft, habe ich jedenfalls in keines der Skript-Files eingebaut.

 

[coco722]

Problem... habe im aktiven System avme 06.36 mit modfs-0.3.2.tgz im update modus die de avm 06.51 bearbeitet...das neue System 06.51 wurde auf mtd2/mtd3 geschrieben.
Nach reboot ist des gesamte Webserver zerschossen, bzw. nicht erreichbar (weder unter 192.168.178.1 noch unter Notfall IP 169.254.1.1), es wird explorer ERR_NOT_FOUND angezeigt.
Dennoch, Internet geht. Ping auf 192.168.178.1 geht...shellinabox ist nicht vorhanden/erreichbar. telnetd habe ich noch nicht probiert...
Wenn ich einen Konsolenzugriff bekomme (und ja...telnetd per Telefon-Aktivierung geht), wie kann ich einen Neustart ins andere System bewerkstellingen (also zurück ins vorherige) ?


Prüfen:
# grep linux_fs_start /proc/sys/urlader/environment
linux_fs_start 1

Wie kann ich das Umstellen, mit echo (wie wäre die genaue Befehlszeile) ? Danke im voraus.

Evtl. falsche Fragestellung. Auf der Telnet-Kommandozeile, was muss eingegeben werden, für ein reboot ins linux_fs_start 0 (also das mtd0/mtd1) ?

 

[PeterPawn]

https://github.com/PeterPawn/YourFritz/blob/master/switch/switch_system

Wobei ich bei funktionierendem Telnet-Zugriff schon mal nachsehen würde, woran es nun scheitert ... z.B. wäre es eine Möglichkeit, daß das Branding nicht zum System paßt.

Wenn in dieser speziellen Konfiguration wie bei Dir von "modfs" nach dem Schreiben der neuen Daten auf das andere System umgeschaltet wird, ändert ja modfs selbst das Branding dabei nicht ... das müßte man dann schon noch von Hand machen, wenn man auf einem anderen Weg als per "guibootmanager" das aktive System wechselt. Manchmal hilft ja auch Nachdenken ... so schön solche Automatismen auch sein mögen, sie sollen nur Routinearbeiten abnehmen und nicht das eigene (Nach-)Denken ersetzen.

In so einem Falle müßte man dann schon den Neustart über das GUI ausführen (und nicht über ein simples "reboot"-Kommando), damit da tatsächlich noch einmal über das Skript eine Umschaltung erfolgt. Dazu reicht es normalerweise, nach dem erfolgreichen "modfs" noch ein weiteres "modfs undo" aufzurufen, denn dabei passiert eigentlich nichts anderes als das Zurücksetzen von "linux_fs_start" auf das gerade laufende System (mehr "undo" gibt es nicht) - nachdem ermittelt wurde, welches das ist. Das andere Skript oben schaltet hingegen bei jedem Aufruf erneut um, egal welches System gerade läuft und welches beim nächsten Start verwendet werden soll.

 

[coco722]

Halllo...hab auf der telnet-Konsole den bootmanager_7490 runtergeladen und laufen lassen und dort das neu zu startende System gewählt und rebootet...bin jetzt wieder auf dem ersten System (mit Web GUI, etc.)...alles wieder ok. Der GUI war beim alternativen System tatsächlich zerschossen (Korrektur: nicht wirklich, nur nicht erreichbar), weil das System mit avme aufgerufen wurde (statt avm).
Hab jetzt auch (wieder) die Dropbox um bei einem Start des alternativen Systems das notwendige "avm" branding zu setzen.


Alles (wieder) bestens. Probiere jetzt die modfs-Starter...fs4 auf dem 06.51 System...(telnetd ging direkt, ohne vorher anzuschalten... aus- und wieder anschalten mit Wahlhilfe geht problemlos).

der Status ist wohl unverändert...modfs-starter geht nicht als pseudo-update auf der 06.51...

 

[KunterBunter]

Der GUI war beim alternativen System tatsächlich zerschossen, weil das System mit avme aufgerufen wurde (statt avm).

"Zerschossen" wird da gar nichts. Es ist noch alles vorhanden, nur eben nicht in dem Verzeichnis, welches aufgerufen wurde.

 

[coco722]

@KunterBunter - völlig richtig. Nur im ersten Moment dachte ich "zerschossen", aber es war ja Internet da, also lief es (nur halt nicht richtig...)... hatte deswegen hinzugefüht "bzw. nicht erreichbar"... Aber nun ist alles wieder gut... mit Hilfe von PeterPawn's bootmanager_7490 !

 

[KunterBunter]

Nur im ersten Moment dachte ich "zerschossen", aber es war ja Internet da, also lief es

Als Informatikerin hast du da eine etwas eigenwillige Auffassung, wie das Dateisystem für die GUI aufgebaut ist.

 

[coco722]

Hmm...wieso klingt das trotz smiley nicht besonders nett... als Informatikerin hab ich (Studium vor xx Jahren) schon lange mit ganz anderen Sachen zu tun (Spezialisierungen sind sehr weit gefächert...). Dennoch tut's wenig zur Sache andere zu "berichtigen" oder jedes Wort auf die Goldwaage zu legen... auch wenn's nett gemeint ist, kommt weniger gut an. Dennoch, ein cheers nach Boca Raton.

 

[coco722]

(...) Neustart über das GUI ausführen (...) .

Beim aktuellen System (branding 'avm' und fw 06.51 auf mtd2/mtd3) sieht der Neustart-screen wie nachfolgend aus - dropdown-menue hat (nur) die Werte 'avm' oder '1und1'.
Will man nun aufs andere System (ein 'avme' fw 06.36 auf mtd0/mtd1) wird aber (vermutlich) das branding nicht wie erforderlich auf 'avme' gesetzt. Was tun ?

 

[PeterPawn]

Einfach einmal die Auswahl mittels Radiobutton hin- und herzuschalten, sollte eigentlich schon ausreichend sein ... wenn ich da nichts falsch interpretiere, ist nur der "initiale Zustand" der "span"-Elemente vertauscht gewesen und sogar bei der Wahl des "Neu starten"-Buttons dürfte das kein Problem sein, weil dabei trotzdem der richtige Wert (entweder "running_branding" oder "alternative_branding", in Abhängigkeit vom Wert "running" oder "alternative" für das "linux_fs_start"-Element - das ist der Radiobutton) gesetzt wird. Es ist - wenn ich es richtig sehe, ich weiß ja auch nicht, ob das eine Version vor oder nach #447 ist - nur ein reines Anzeigeproblem ... es wird eben beim Roundtrip der jeweils falsche Abschnitt ein- bzw. ausgeblendet, das hatte ich ja in den vorhergehenden Screenshots noch selbst gesehen und dann entsprechend schon korrigiert. Beim Wechsel der Auswahl wird dann aber wieder richtig "umgeschaltet" bei der Sichtbarkeit und so dürfte schon ein Klick ausreichen ... die Korrektur kann man dann beim nächsten Update mitmachen.

 

[coco722]

Hallo PP, ja es stimmt vollkommen was du sagst. Es funktioniert korrekt. Danke.

 

[KingTutt]

@KingTutt:
Mit ein wenig Bastelarbeit (in erster Linie wahrscheinlich das Simulieren einer passenden Umgebung im procfs, da wird das Urlader-Environment und die MTD-Tabelle gebraucht) sollte sogar das komplette "modfs" auf einem x86-Linux laufen können.

Genau das war Kern der Frage. Das "precheck" sucht natürlich nach dem Urlader-Environment. Muss man das simulieren oder kann man auch einfach installieren mit richtigem FRITZ!OS-Root-FS?

Die Alternative ist halt der Aufruf eines "modscripts" von Hand ... solange die vier Parameter stimmen und die benötigten Kommandos existieren (notfalls nimmt man eine x86-Busybox dafür her), sollte das auch unter jeder anderen Shell (bzw. eher unter bash als unter csh oder ksh) funktionieren ... mir fällt jetzt nicht ein, was da außer "cat" und "sed" verwendet werden sollte - solange das angegebene Verzeichnis ein ausgepacktes FRITZ!OS-Root-FS ist, braucht das "gui_boot_manager_v0.2" nicht einmal mehr (wie das vorhergehende) einen Zugriff auf das procfs, weil die Brandings nicht mehr aus $OEM (war nur ein einzelnes vorher, damit das richtige "reboot.lua"-File geändert wurde, wenn es mehrere gab), sondern aus dem Dateisystem gelesen werden.

Die vier Parameter zu übergeben ist ja nicht so schwer, wenn allerdings Infos aus dem Urlader-Environment beim installieren benötigt werden (der "precheck" testet ja extra die Verfügbarkeit) schlägt das ganze natürlich trotzdem fehl.

So, für den Fall, dass es noch jemanden interessiert:
Das "precheck" beklagt sich wie erwartet über das fehlende '/proc/sys/urlader/environment' <-- nicht weiter tragisch
das 'find' warnt darüber, dass die Option -maxdepth nach -type steht (welches keine Option ist) daher sollte die Option vor anderen Argumenten stehen

./gui_boot_manager_v0.2 de fwmod_kernel_113.06.05/original/filesystem auto install

Wenn man das ganze als non root ausführt, gibt es neben der Warnung von find noch den Fehler, dass das chmod root.root und das chgrp nicht durchgeführt werden kann. Entweder holt man das im Anschluss als root nach oder kommentiert das aus (man sollte natürlich sicherstellen, dass die Rechte vor dem Packen des Images korrekt gesetzt sind!).

./gui_boot_manager_v0.2 de fwmod_kernel_113.06.05/original/filesystem auto postcheck

Gibt interessanter Weise (außer der Warnung von find) gar nix aus. Ein Blick in den Code zeigt, das nur im Fehlerfall etwas ausgegeben wird <-- also alles gut so weit

Ein erneuter Aufruf von bestätigt das mit

./gui_boot_manager_v0.2 de fwmod_kernel_113.06.05/original/filesystem auto precheck

bestätigt das mit "Die Modifikation wurde bereits angewendet."


Wenn modfs jetzt noch einen Schalter hätte, um ein Image direkt zu flashen (ohne es erst aus und wieder ein zu packen), könnte man ein selbst gebautes Image auch ohne freetz z.B. mit SIAB oder Telnet direkt selbst flashen

 

[PeterPawn]

Wenn modfs jetzt noch einen Schalter hätte, um ein Image direkt zu flashen

Ist gerade in Arbeit: https://github.com/PeterPawn/modfs/commit/8214196e405bf95c539e5b9181ff0c3e7081953f ... aber dauert schon noch etwas.

EDIT: Dem (in den Optionen ohnehin eingeschränkten) "find" der Busybox ist die Reihenfolge ziemlich egal ... ich würde (wie oben erwähnt) auch eher auf die Busybox-Applet als auf die Host-Utilities setzen - notfalls kriegt man das über eine vorhergehendes "busybox sh" als Shell-Aufruf hin, wenn die verwendete Busybox so erstellt wurde, daß sie zuerst nach internen Applets sucht, bevor sie sich an den PATH heranmacht. Aber die Parameter-Reihenfolge da zu tauschen, ist auch die kleinste Übung, mache ich einfach mal mit.