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

KingTutt · 18 Feb 2016

So, habe das ganze Vorhaben jetzt mal gemäß Anleitung durchgespielt. Ein 06.50 ausgepackt, mit KDG Patch, LED-Patch, SIAB und guibootmanger 2 versehen, dann alles wieder zusammenpackt und aufgespielt. Hat so weit auch alles im ersten Anlauf geklappt

Das SIAB habe ich mit dem x86 unsquashfs4-be ausgepackt und passend integriert, so dass es bei Booten schön gestartet wird. Jetzt hat man quasi auf der 06.50 eine SIAB und kann von da aus wieder eine selbst modifiziert FW 06.51 mit SIAB einspielen usw. (mit dem neuen modfs Parameter zum direkten Update)

Was mir nicht ganz klar geworden ist: Nach Deinen Beschreibungen wird bei einem Recover immer das aktive System überschrieben. Wann wird denn auf das inaktive System geswitched? Bei einem normalen FW Update? Dem widerspricht zumindest der guibootmangerv2.
Ich habe eine jungfräuliche 7490 von 06.30 meine modifizierte 06.50 upgedated über die Web-GUI. Der guibootmangerv2 sagt aber (siehe Bild unten), dass nur ein System verfügbar ist. Ich hätte angenommen, dass ich zwischen dem originalen 06.30 und dem neuen 06.50 umschalten kann. Oder liegt das an der Fehlermeldung (mount von mtdbloock1 ist fehlgeschlagen), die ebenfalls sichtbar ist, so dass nur die Version im inaktiven System nicht angezeigt werden kann?

PeterPawn · 18 Feb 2016

@KingTutt:
Die 06.50 kann das Dateisystem der 06.30 (SquashFS3) nicht mounten, daher läßt sich die Version des anderen Systems nicht auslesen ... auch keine Brandings, usw.

Da es in absehbarer Zeit wohl keine Boxen mehr geben wird, die in der einen Partition einen 2.6.32- und in der anderen einen 3.10.73-Kernel haben, mache ich mir auch keinen Kopf mehr, wie man das beheben könnte (ginge sicherlich mit Extrahieren von Dateien anstelle des Mountens, lohnt aber m.E. den Aufwand nicht).

Beim Recovern (von AVM) werden die "kernel"- und "filesystem"-Partitionen überschrieben (siehe originale /sbin/flash_update) - das kann man natürlich mit einer entsprechenden Anpassung dann wieder ändern, aber bei AVM bleibt eben das aktive System aktiv und wird überschrieben. Beim Update werden hingegen die "reserved"-Partitionen beschrieben und im Erfolgsfall die "linux_fs_start"-Variable umgeschaltet.

KingTutt · 18 Feb 2016

OK, das SquashFS3 erklärt es, hätte ich eigentlich selbst drauf kommen können

Gut gut, dann werde ich jetzt ein wenig mit EVA spielen und prüfen, ob man analog zu der Edition von O2 auch bei der Edition EWE mit dem entfernen der Provider Variablen im environment das AVM Recovery dazu bringen kann, seinen Dienst zu verrichten.

PeterPawn · 18 Feb 2016

Neue Version 0.3.3 mit folgenden Änderungen:

- es gibt neue Parameter beim Aufruf (install, installfs, installroot), die das danach angegebene Image ohne weitere Modifikationen einfach nur installieren und zwar (in der vorne angeführten Reihenfolge) "Kernel, Wrapper-Partition und Root-Image", "Wrapper-Partition und Root-Image" oder "nur Root-Image"

- das Archiv-File enthält jetzt eine statisch gelinkte Busybox 1.24.1 aus der Freetz-Toolchain, mit ein paar Abwandlungen aus diesem Commit-Stand meines Forks: https://github.com/PeterPawn/freetz/tree/5633f901d07229bf4b20365f50aafb6b8184f26d
- um die bereitgestellte Busybox selbst zu erstellen, braucht es also den o.a. Patch-Stand und die Ausgabe von "bbconfig" aus eben dieser Busybox, die auch noch einmal gesondert im "bin"-Unterverzeichnis vom modfs liegt, damit man nicht erst die Busybox aufrufen muß
- die Bereitstellung dieser Binärversion ist auch kein Selbstzweck ... es ist nur wesentlich einfacher, künftige Modifikationen als "unified patch file" mit dem dort enthaltenen "patch"-Applet anzuwenden (mod_default_show_mac macht bereits davon Gebrauch) und wenn es schon eine binäre Datei gibt, dann kann die ruhig auch noch weitere Applets enthalten, die nicht im direkten Zusammenhang mit "modfs" benötigt werden

- für die Auswertung von Angaben zum Zielsystem (Kernel-Version, FRITZ!OS-Version, Brandings, usw.) gibt es jetzt entsprechende Funktionen direkt im "modfs" und diese Angaben werden den "modscripts" über das Shell-Environment zur Verfügung gestellt, damit muß das nicht jedes "modscript" erneut enthalten

- die Namen der Modifikationen wurden geändert (das paßt jetzt jeweils in eine einzelne Zeile) und alle "modscripts" als Zugaben in der Archiv-Datei wurden an die Verwendung der o.a. Variablen zum Zielsystem angepaßt

- die Modifikation "mod_mount_by_label" ist jetzt für Versionen vor und nach 06.36 verfügbar, nach 06.36 schaltet sie lediglich den AVM-Code zur Auswertung von Volume-Labeln "zwangsweise" scharf, indem die Abfrage der "usb.cfg" durch ein festes "yes" ersetzt wird

- für mod_profile wurde der Pfad der zusätzlichen Datei auf /var/custom/etc/profile geändert, um besser zur Verwendung von "custom images" a la "modfs-Starter" zu passen

- gui_boot_manager_v0.2 sollte jetzt auch mit "pre-06.36"-Firmware funktionieren und auch dort das Branding bei Bedarf umschalten können

- neues (deaktiviertes) "modscript" mit dem Namen "template", das nur die Verwendung der oben erwähnten Environment-Variablen dokumentieren soll

- neue Modifikation für Firmware > 06.36 (das wird aber vom Skript nicht abgefragt), die auch beim "responsive design" in der Übersicht der "Netzwerkverbindungen" die Spalte mit der MAC-Adresse standardmäßig anzeigt, ohne daß man sie erst langwierig aktivieren muß (was sich die Firmware auch nicht merkt)

In ein paar Tagen (wenn event. Fehler noch beseitigt sind, aber ich habe eigentlich alle Änderungen selbst mind. einmal getestet) erfolgt ein "freeze" für die 0.3.3 und es geht mit 0.3.4 weiter ... aber vorläufig wüßte ich gar nicht, was da - außer ggf. weiteren Skripten für konkrete Modifikationen - als nächstes kommen sollte.

BTW ... irgendwo habe ich mal geschrieben, daß mir der Umstand auf den Geist gehen würde, daß man beim Aufruf der Login-Seite der FRITZ!Box den Benutzernamen nicht mehr vorgeben könne ... das ist gerade bei Bookmarks mit Links zum Login in FRITZ!Boxen per Fernwartung ein erheblicher Vorteil in meinen Augen. Das geht aber nach wie vor noch, aus der alten URL "https://somewhere/login.lua?username=benutzer" wird jetzt nur "https://somewhere/?username=benutzer" ... also die Angabe des Lua-Files entfällt. Gibt man dieses weiterhin in der URL an, bewirkt die Angabe des Benutzernamens nichts - daher auch meine (falsche) Vermutung. Somit ist dafür aber keine Änderung in den Lua-Files von AVM notwendig ... genau das hatte ich aber hier irgendwo weiter vorne behauptet.

coco722 · 19 Feb 2016

modfs-0.3.3.tgz angewendet auf jeweils das andere System - funktioniert bei mir nicht, die GUI Auswahl (System, branding) fehlt komplett. Betreff busybox bleibt 1.22.1 .

modfs hatte folgende Fehlermeldung:
Auswahl des zu startenden Systems und des Brandings in der "Neustart"-Seite angewendet werden? (j/N) j Überprüfen der Voraussetzungen für die Modifikation ... OKgrep: /var/media/ftp/1455886491/squashfs-root/usr/www/1und1/system/reboot.lua: No such file or directory Modifikation wird ausgeführt ... OKsed: can't create temp file '/var/media/ftp/1455886491/squashfs-root/usr/www/1und1/system/reboot.luaeJP2hk': No such file or directory sed: can't create temp file '/var/media/ftp/1455886491/squashfs-root/usr/www/avm/system/reboot.luacflUNp': No such file or directory Überprüfen des Erfolgs der Modifikation ... Fehler (1)grep: /var/media/ftp/1455886491/squashfs-root/usr/www/1und1/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

screen-Neustart-gui_0.2-fehlt-komplett.jpg

PeterPawn · 19 Feb 2016

Gerade noch einmal bei mir getestet (modfs update FRITZ.Box_7490.113.06.51.image) und folgendes Ergebnis erhalten:

Code:

Die Modifikation 'enable system and branding selection from GUI (v0.2)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable system and branding selection from GUI (v0.2)' mit folgender Beschreibung
Auswahl des zu startenden Systems und des Brandings in der "Neustart"-Seite
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

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

Damit wird es vielleicht irgendwo an der Konstellation mit einmal "avme" und einem "avm 1und1" liegen ... das braucht die Debug-Ausgabe von "modfs" für eine Fehlersuche. Wie diese erstellt werden kann (und wie man sie auslesen muß), ist irgendwo in #1 verlinkt - den richtigen Beitrag (auch in diesem Thread) dafür habe ich jetzt auch nicht in meinen Bookmarks.

Aus dem Bauch heraus würde ich allerdings behaupten, daß da einfach das NAND-Filesystem unter /var/media/ftp voll ist und es schon beim Auspacken wohl ein Problem gibt (das vielleicht vom "spinner" verdeckt wird, wobei da eigentlich auch ein Return-Code <> 0 auftauchen müßte). Mir fällt ansonsten keine (theoretische) Möglichkeit ein, wieso da die Datei aus dem originalen AVM-Dateisystem beim Aufruf des "modscripts" nicht existieren könnte ... die anderen Fehler resultieren aus dem "sed"-Aufruf mit i-Option, wo das "sed"-Kommando selbst eine temporäre Kopie erstellt (daher die unterschiedlichen Endungen der Namen).

In der Debug-Ausgabe sieht man dann aber auch, welches System da aktiv ist und mit welchem Image "modfs" arbeiten sollte ... ich habe zweimal mit Branding "avme" getestet und eigentlich hat sich nur die "Umgebung" für die "modscripts" geändert. Da allerdings die internationale Version die einzige mit nur einem Branding ist (das sollte oben die Fehlermeldung aus einem Update auf eine deutsche Version sein, denn nur diese hat die beiden Brandings "1und1" und "avm" an Bord), könnte es da noch Überraschungen geben, aber auch das hat bei meinem eigenen Test einwandfrei funktioniert in der Funktion "get_first_branding".

coco722 · 19 Feb 2016

Mit modfs-0.3.2. beide Systeme abgeändert (jeweils das inaktive), nun geht das GUI wieder mit Auswahl des brandings. Scheint doch, dass irgendwas beim modfs-0.3.3. (bei meiner FW Konstellation) nicht funktioniert wie es sollte. Demnach, genau dieselbe Vorgehensweise mit modfs-0.3.2. geht und mit modfs-0.3.3. leider nicht.

PeterPawn · 19 Feb 2016

Wie gesagt ... ich finde bei mir keinen Fehler in der Richtung (habe im Moment auch keine Box in der Nähe, die sowohl eine internationale als auch eine deutsche Version enthält) und ohne das entsprechende Debug-Protokoll (bzw. hier wären es ja dann sogar zwei) ist da wenig zu machen.

Auch die Information, ob das Problem trotz der Verwendung eines ausreichend großen USB-Sticks mit einem Linux-Dateisystem auftritt und ob es tatsächlich reproduzierbar ist, hätte ich gerne, bevor ich mich auf eine Suche mache und es hinterher ein Anwendungsfehler war oder meinetwegen ein Mißverständnis.

So ein USB-Stick mit einem "native filesystem" war ja mal die ursprüngliche "Umgebung", von der ich ausgehe - bei mir lege ich sogar immer eine entsprechend große Dummy-Datei im NAND-Flash an, damit der möglichst wegen Platzmangel dort nicht ausgewählt wird - auch das ist irgendwo in den Weiten dieses Threads mal beschrieben worden. Die Verwendung des NAND-Flashs ist schon aus Gründen der Geschwindigkeit eher keine gute Idee ... das Ausweichen in den NAND-Flash oder die Verwendung des ext3-Images auf einem unpassend formatierten Volume sind am Ende alles nur Notlösungen und eher "grenzwertig" - letztlich nur die letzte Chance, daß es überhaupt funktionieren könnte auch in einer weniger gut geeigneten Umgebung.

Die Bemerkung

coco722 schrieb:
Betreff busybox bleibt 1.22.1 .

läßt mich schon vermuten, daß wir aneinander vorbeischreiben ... oder ich diesen Satz vollkommen falsch verstehe, denn natürlich ändert "modfs" von sich aus nichts an der Busybox-Version in der Firmware - damit bleibt das logischerweise genau die Version aus dem Source-Image von AVM, wenn man da nicht selbst Hand anlegt. In meiner Beschreibung ist zwar die Rede davon, daß jetzt eine statisch gelinkte Busybox im Archiv enthalten ist, da sollte aber gleichzeitig auch stehen, daß der eigentliche Antrieb dazu das Nachrüsten eines "patch"-Applets war und nicht der Austausch der Busybox in der Firmware.

Sollte da tatsächlich ein reproduzierbarer Fehler in der Version enthalten sein, suche ich den schon (auch zeitnah) ... aber ich würde nur ungern dort Zeit investieren, solange nicht 100%ig feststeht, daß es sich tatsächlich um ein Problem der Version handelt (und nicht eventuell doch um einen Fehler in der Anwendung von "modfs") und dafür ist der "Kreuztest" mit Schlußfolgerung leider weniger gut geeignet als das Debug-Log, das ich ja gerade für solche Fälle implementiert habe, damit niemand das "verbal" beschreiben muß - mit allen dann denkbaren Fehlerquellen.

coco722 · 20 Feb 2016

modfs-0.3.3.tgz wurde mit 'update' u. Angabe v. original AVM image gestartet, GUI 0.2 wird nicht ordnungsgemäss installiert, GUI 0.2 nicht vorhanden;
das Ganze nochmal mit
modfs-0.3.2.tgz (auch update mit Angabe einer AVM image) funktioniert einwandfrei, inklusive GUI 0.2 mit System- und Branding Wechsel.

Eine im modfs-Skript automatische Implementierung der bb 1.24.1 wäre schön (wo diese bb Version schon im neuen modfs Paket mit enthalten ist).

maulich · 20 Feb 2016

@GUI 0.2:
Hm. Hier bei funktioniert das problemlos. Hast Du modfs-0.3.3 in ein komplett neues Verzeichnis kopiert oder eine alte Version von modfs überschrieben/ergänzt?
Ich entpacke die modfs-Versionen jeweils in eigene Verzeichnisse, damit ich sicher sein kann, daß nicht irgendwas durch eine alte Version "kontaminiert" wird...

Und wenn Du die genauen Fehlermeldungen für uns hättest, wäre es evtl. auch besser nachzuvollziehen, was da passiert bzw. nicht passiert.

@busybox:
Ich persönlich finde es besser, daß über das "copy_binaries" modscript zu lösen. Wer weiß, ob am Ende doch noch irgendwas fundamental anders bei Version 1.24.1 womit das OS nicht klar kommt (weil es z.B. einen Parameter erwartet, den es in dieser Version nicht gibt).
Das erstellen der nötigen "binaries_113_3.10.73.tgz" ist ja nicht schwer und so bleibt eine gewisse Modularität gewahrt.

Ich erstelle mir das z.B. so (gibt sicher elegantere Lösungen, aber es macht was ich will):

Code:

mkdir -p /var/tmp/work/bin
cp <Pfad-zu-modfs>/bin/VR9/busybox /var/tmp/work/bin
cd /var/tmp/work
tar cvzf <Pfad-zu-modfs>/files/binaries_113_3.10.73.tgz *

Im work-Verzeichnis lassen sich natürlich noch andere Dateien und Verzeichnisstrukturen anlegen.

Und mit

Code:

tar -tf <pfad-zu-modfs>/files/binaries_113_3.10.73.tgz

lassen sich die Pfade nochmal überprüfen. das "copy_binaries" modscript entpackt das binaries-Archiv relativ zum Systemroot.

PeterPawn · 20 Feb 2016

Eine automatische Ersetzung der Busybox wird es von mir nicht geben ... wer das will, müßte mit der Kommandofolge

Code:

mkdir files/bin;cp -a bin/$HWRevision/busybox files/bin/;tar -C files -c bin | gzip -c >files/binaries_$CONFIG_VERSION_MAJOR_$(uname -r).tgz

das passende Archiv erstellen (Kontrolle des Inhalts mit

Code:

gunzip -c [I]dateiname[/I] | tar tv

- die Busybox muß unterhalb von "bin" liegen) und dann "copy_binaries" verwenden, wie es @maulich im anderen Thread getan hat. Die Umgebungsvariablen (HWRevision / CONFIG_VERSION_MAJOR) sollten passen, solange es um dieselbe Box geht (also kein "cross-mod" ist

) und die Ausgabe von "uname -r" paßt natürlich auch nur solange (bei 2.6.32.61 wäre sie sogar in der oben gezeigten Form falsch, weil nur 3 "Stufen" vorhanden sein dürfen), wie das aktuelle und das zu modifizierende System dieselbe Kernel-Version verwenden. Die Angabe ist nur deshalb mit "Variablen", damit es über mehrere Boxen paßt ... wer die Werte der eigenen Box kennt, kann die natürlich direkt angeben.

Es hat Lizenzgründe, warum ich zwar eine Busybox beilege, diese aber nicht automatisch in die FRITZ!OS-Firmware einbaue - jedenfalls nicht als Ersatz der Busybox von AVM (wenn sie daneben liegen würde, wäre es mir wieder egal, bringt dann aber sicherlich nicht den gewünschten Effekt). Eine entsprechend vorbereitete "binaries"-Datei müßte erstens (zumindest wohl künftig) auch mehrere Boxen berücksichtigen, zumindest als Symlink und wenn man das Namensschema beibehält und zweitens müßte man dann bei (bzw. sogar wegen) Updates der Busybox auch das Archiv mit aktualisieren, wenn man das quasi "offiziell" macht. Das binde ich mir nicht (sehenden Auges) ans Bein ...

EDIT: Oops ... doppelt hält besser. ;-)

EDIT2: Die (Fehler-)Meldungen (zumindest eines Falles) beim Integrieren von gui0.2 gab es ja schon vorher, die sind aber eben auch nur wenig aussagekräftig ... ich mache gerne noch einmal darauf aufmerksam, daß ich tatsächlich genau für solche Fälle die Debug-Funktion eingebaut habe ... da werden dann eben auch die internen Fehlercodes protokolliert und so kann man ein Problem bis zu seinem Ursprung verfolgen und muß nicht anhand der Auswirkungen erraten, was alles die Ursachen sein könnten.

coco722 · 20 Feb 2016

@maulich
Cool, danke für die genauen Angaben zum Mit-Einfügen der neuen busybox (habe es etwas anderes gemacht, momentan geht bb 1.24.1 auch ohne Probleme).
Warum bei mir das neue modfs 0.3.3. nicht will, weiss ich nicht (Tatsache ist aber, dass dieselben Schritte mit der vorherigen modfs bestens funktionieren).
Will jetzt noch die neue bb 1.24.1 ins modfs-Starter einfügen (über entpacken/packen des enthaltenen squash-images), mal schauen was draus wird...

maulich · 20 Feb 2016

PeterPawn schrieb:
Eine automatische Ersetzung der Busybox wird es von mir nicht geben ... wer das will, müßte mit der Kommandofolge

Code:

mkdir files/bin;cp -a bin/$HWRevision/busybox files/bin/;tar -C files -c bin | gzip -c >files/binaries_$CONFIG_VERSION_MAJOR_$(uname -r).tgz

...

EDIT: Oops ... doppelt hält besser. :wink:

Naja, in diesem Fall doch ganz gut... Deine Version ist eleganter (und wurde von mir sogleich übernommen) :smile:

Zu dem Absatz bezüglich der Lizenzgründe:
Da irgendwelchen Nerv zu riskieren lohnt die Sache wahrlich nicht...Außerdem finde ich die vorhandene modulare Lösung sehr praktisch. Das ganze bleibt sehr flexibel und ich kann nachvollziehen, was ich wo hin kopiere und mir meine Box ganz alleine kaputtbasteln :grin:

PeterPawn · 20 Feb 2016

Ich habe mich nun (vermutlich endgültig) doch durchgerungen, ein "modscript" für die Integration von SIAB anstelle des Telnet-Daemons (bzw. parallel, denn die sind ja unabhängig und das "anstelle" bezieht sich mehr darauf, daß die Leute dann hoffentlich den sichereren Weg über HTTPS anstelle von Telnet nutzen, wenn sie nur gelegentlich diese Dienste brauchen) "anzubieten" ... das wird dann praktisch den Inhalt eines "modfs-Starter"-Images und ein Skript zur Installation in das SquashFS-Image anstelle der wrapper-Partition "vereinen". Die ganze "Ziererei" bei binären Dateien bringt ja auch nichts, wenn die Leute dann doch aus allen möglichen anderen Quellen sich ihre Binärdateien besorgen, anstatt selbst zu übersetzen und bei SIAB bin ich mit den "modfs-Starter"-Images ja ohnehin schon mir selbst untreu geworden.

Im Moment schwanke ich noch bei den Möglichkeiten der Einbindung in das AVM-System ... einerseits könnte man das wie AVM so regeln, daß es als CGI tatsächlich nur dann ausgeführt wird, wenn man die URL aufruft und auf der anderen Seite könnte ich mir auch vorstellen, daß man einen Button für den Start eines Services irgendwo einfügt (dann hat man quasi "doppelte Sicherheit", weil neben der (späteren) Anmeldung auf der Kommandozeile noch die Kenntnis von gültigen GUI-Credentials zum Start des Services notwendig wäre und das könnten durchaus unterschiedliche Konten sein - ich weiß nicht genau, welche Zugriffsrechte "ar7login" für einen Account erfordert, wenn es um den Shell-Zugriff geht und ob da nicht sogar ein Account für das NAS funktionieren würde, der ja meist eher keinen Shell-Zugriff haben sollte), wo man etwas leichter herankommt als in der Support-Seite von AVM ... wo nun aber eben schon "Rudimente" der AVM-Version von SIAB aus den Developer-Versionen liegen. Die Möglichkeiten sind vielfältig und wenn ich noch eine Weile darüber grübele, mein Gesicht sicherlich ebenfalls. Wahrscheinlich wird es ohnehin wieder die "falsche" Lösung für die überwiegende Zahl der Nutzer werden, egal welchen Weg ich wähle. Wenn man so eine "nur bei Bedarf"-Lösung umsetzt, hat das aber auch den Vorteil, daß es sich in den Support-Daten nicht niederschlägt und man sich nicht über Reaktionen des Support "ärgern" muß, auch wenn gemeldete Probleme mit originaler Firmware genauso auftreten (so eine SIAB-Integration ändert ja - alleine - noch nichts an AHA oder WLAN).

Theoretisch könnte man das auch gleich mit "dropbear" und SSH-Zugriff ebenso machen, aber dazu muß man dann dem "dropbear" erst einmal beibringen, den lokalen Server-Key aus einem X.509-Zertifikat zu lesen und - wenn man es "sicherer" will als bei der Kennwort-Authentifizierung, damit sich dann auch die Frage der AVM-Zugriffsrechte i.V.m. ar7login gar nicht mehr stellt - irgendwo die pubkeys für eine schlüsselbasierte Authentifizierung so zu hinterlegen, daß da nicht einfach jemand weitere Schlüssel hinzufügen kann (jedenfalls nicht leichter als auf anderen Wegen eines "Einbruchs" in die Box). Daß dabei dann wieder die Einbindung als CGI nicht funktioniert und so ein "Start service"-Button wieder die einheitlichere Lösung wäre, macht die Entscheidung für einen Weg zum Starten von SIAB auch nicht gerade einfacher.

Obwohl das keine neue Version von mdfs werden sollte, würde ich gerne dabei dann auch gleich den "gui_boot_manager_v0.2" reparieren, wenn es tatsächlich ein Problem mit der Integration geben sollte. Es wäre also nett, wenn da mal eine passende Debug-Ausgabe gepostet würde ... man kann ja durch die Angabe eines "Ziel-Images" als Parameter hinter dem Namen des Quell-Images dafür sorgen, daß nur der "modfs"-Ablauf einmal ausgeführt und das System am Ende gar nicht geändert wird. Die Abstraktion von dieser Variante auf eine mit dem Schreiben des neuen Images ist ja problemlos möglich, denn wenn es ein Problem gibt, liegt das eher im "modscript" begründet als in "modfs" selbst.

@maulich:
Es gibt immer zig Wege nach Rom in Shell-Code ... ich separiere bei tar/gzip das inzwischen schon automatisch, weil die AVM-Versionen meines Wissens beim tar-Applet die Behandlung von komprimierten Archiven nicht eingebaut haben und die separate Verwendung mit beiden Versionen klappt, was Nachfragen von Leuten mit einer AVM-Busybox vermeiden sollte. Ansonsten sehe ich das mit dem "Bewußtwerden" der Änderungen ganz genauso, das ist auch der Grund, warum ich bei allen "modscripts" im Download-Archiv das "o+x"-Flag wieder entfernt habe und es somit keine "automatischen Skripte" mehr gibt. Damit müssen die Leute zwar jetzt öfter "j" drücken, aber so kann niemand behaupten, er wisse von einer Änderung nichts.

splenditnet · 20 Feb 2016

PeterPawn schrieb:
In ein paar Tagen ... erfolgt ein "freeze" für die 0.3.3

Hallo PeterPawn und andere Interessierte,
nachdem das busybox-Binary mit patch-Applet in modfs-0.3.3 aufgenommen wurde, sind Menü-Anpassungen sehr einfach möglich;
daher habe ich als Fan von Automatisierungen den LED-Menu-Patch aus http://www.ip-phone-forum.de/showthread.php?t=282809&page=2&p=2132959&viewfull=1#post2132959
als Modscript mod_menu_led_on_off analog zu mod_default_show_mac in modfs-0.3.3 eingepflegt.

Code:

#[I] ls -la modscripts/[/I]
drwxr-xr-x    2 root     root          4096 Feb 20 15:08 .
drwxr-xr-x    6 root     root          4096 Feb 20 15:12 ..
-r-xr-xr--    1 root     root           649 Feb 18 10:05 copy_binaries
-r--r--r--    1 root     root          1574 Feb 18 15:09 dectcmds.modscript
-r-xr-xr--    1 root     root          3646 Feb 18 13:01 edit_rcuser
-r--r--r--    1 root     root         11726 Feb  5 19:19 gui_boot_manager_v0.1
-rwxrwxrw-    1 root     root         19208 Feb 18 19:17 gui_boot_manager_v0.2
-r-xr-x---    1 root     root          1913 Feb 18 16:02 mod_default_show_mac
-r-xr-xr--    1 root     root          1144 Feb 18 16:01 mod_enable_telnet
-r-xr-xr--    1 root     root          1932 Feb 20 15:34 mod_menu_led_on_off
-r-xr-xr--    1 root     root          2174 Feb 19 08:28 mod_mount_by_label
-r-xr-xr--    1 root     root          1272 Feb 18 13:06 mod_profile
-r-xr-xr--    1 root     root          2164 Feb 18 16:02 mod_rc_tail_sh
-r--r-----    1 root     root           645 Feb 18 16:03 template
-r--r--r--    1 root     root          5266 Feb 18 14:29 yourfritz_hooks
#

# [I]ls -la modscripts/mod_menu_led_on_off[/I]
-r-xr-xr--    1 root     root          1932 Feb 20 15:34 modscripts/mod_menu_led_on_off
#


# [I]cat modscripts/mod_menu_led_on_off[/I]
# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME show led display options menu
# DESCRIPTION en
# display menu to enable/disable of LED
# DESCRIPTION de
# Menu mit LED Einschalt-/Ausschalt-Option einblenden
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ ${#4} -eq 0 ] && exit 59 # invalid call
#
# variables
#
rc=0
check_filename="$rootdir/usr/www/$TARGET_BRANDING/menus/menu_data.lua"
#changed='["lua"] = "system/led_display.lua",'
changed="\"lua\"\] = \"system\/led_display.lua\","
#
# apply
#
patch_file()
{
        local home=$(pwd)
        cd $rootdir
        $home/bin/$HWRevision/busybox patch -p0 2>/dev/null <<EOT
--- usr/www/$TARGET_BRANDING/menus/menu_data.lua
+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
@@ -498,6 +498,11 @@
 ["lua"] = "system/infoled.lua",
 ["help"] = forLuaOnly and "hilfe_system_infoanzeige"
 } or nil
+pageData["led"] = {
+["show"] = true,
+["lua"] = "system/led_display.lua",
+["help"] = forLuaOnly and "hilfe_system_anzeige"
+} or nil
 pageData["keyLo"] = {
 ["show"] = true,
 ["lua"] = "system/keylock.lua",
EOT
        cd $home
}
#
# execute steps
#
case $step in
        precheck)
                grep -q "$changed" $check_filename 2>/dev/null 1>&2
                rc=$?
                if [ $rc -eq 0 ]; then
                        case "$language" in
                                de)
                                        echo "Die Modifikation wurde bereits angewendet oder ist nicht erforderlich." 1>&2
                                        ;;
                                *)
                                        echo "The startup file is modified already or modification isn't necessary." 1>&2
                                        ;;
                        esac
                        rc=1
                else
                        rc=0
                fi
                ;;
        postcheck)
                grep -q "$changed" $check_filename 2>/dev/null 1>&2
                rc=$?
                if [ $rc -ne 0 ]; then
                        case "$language" in
                                de)
                                        echo "Die Modifikation war nicht erfolgreich." 1>&2
                                        ;;
                                *)
                                        echo "The startup file seems to be unmodified." 1>&2
                                        ;;
                        esac
                        rc=1
                else
                        rc=0
                fi
                ;;
        install)
                for TARGET_BRANDING in $TARGET_BRANDINGS; do
                        patch_file
                done
                rc=0
                ;;
        *)
                rc=59
                ;;
esac
exit $rc
#

würde mich freuen, wenn das mod_menu_led_on_off Skript gerne nach "Community Review" in das modfs-0.3.3 ff. aufgenommen werden könnte.

Gruß
Splenditnet

PeterPawn · 20 Feb 2016

Gerne ... macht es Dir etwas aus, das noch um einen dritten Radiobutton (LED-Anzeige verzögert aus -> Wert 1 -> ar7.cfg-Setting=led_delayed_suspend) zu ergänzen? Wenn schon, denn schon ... dieser "dritte" Zustand ist immer dann nützlich, wenn man beim (Neu-)Start der FRITZ!Box noch sehen will, was Sache ist und dann aber die LEDs gerne aus hätte. Ob und unter welchen Umständen dann dieses "suspend" trotzdem zur Signalisierung von bedeutenden Fehlern per LED führt (z.B. die rote Info-LED bei den Nachrichten vom boxnotifyd), weiß ich bei der 06.50+ auch noch nicht wirklich, aber solange es eine "tri-state"-Einstellung gibt, sollte man die m.E. auch umsetzen.

BTW ... der Patch für die dauerhafte (oder zumindest initiale) Anzeige des FRITZ!Box-Namens in der "Titelzeile" des GUI auch ohne diesen zusätzlichen Klick dorthin, ist eigentlich fertig und kommt demnächst auch dazu ... nur damit sich niemand anders die (doppelte) Arbeit macht.

Ach ja, das gilt auch für die Anzeige der gerade aktiven VPN-Verbindungen (LAN2LAN) in der Übersichtsseite (unter "Verbindungen") ... aus welchem Grund AVM das entfernt hat, habe ich noch nie so richtig verstanden - meine Vermutung, daß die Geschwindigkeit schuld war, würde ich auf der Basis der Anzeige einer modifizierten Seite eher verwerfen, das macht fast keinen Unterschied und beim "responsive design" mit den ständigen asynchronen Requests erst recht nicht.

eisbaerin · 20 Feb 2016

@ splenditnet
Riesen Dank, das habe ich jedesmal per Hand rein geschoben oder vergessen.

@PeterPawn
Das OFF der LED's über die GUI ist schon eines, was verspätet beim Start wirkt.

EDIT: Du meinst aber wahrscheinlich, daß die noch länger an bleiben sollen,
denn es werden in der system/led_display.lua nur die Werte 0 oder 2 übergeben,
und du möchtest ja 1 haben.
Wie lange sind die dann an?

splenditnet · 20 Feb 2016

PeterPawn schrieb:
macht es Dir etwas aus, das noch um einen dritten Radiobutton (LED-Anzeige verzögert aus -> Wert 1 -> ar7.cfg-Setting=led_delayed_suspend) zu ergänzen?
... nur damit sich niemand anders die (doppelte) Arbeit macht.
... die Anzeige der gerade aktiven VPN-Verbindungen (LAN2LAN) in der Übersichtsseite (unter "Verbindungen")

Hallo PeterPawn,
>> macht es Dir etwas aus, das noch um einen dritten Radiobutton (LED-Anzeige verzögert aus -> Wert 1 -> ar7.cfg-Setting=led_delayed_suspend) zu ergänzen?
ich schaue es mir an und liefere einen weiteren diff-Vorschlag hierzu;

den LUA-Patch für "aktiven VPN-Verbindungen (LAN2LAN) in der Homepage" sowie die Statuszeile für "Dynamic DNS" in der Homepage SubFrame "Komfortfunktionen" in der Art wie dies bei FW 06.04 vorhanden war, hatte ich auch auf Radar. Jedoch ist meine Freizeit durch Beruf und Familie eingegrenzt; d.h. hier kann ich keinen Termin nennen, wann ich dies machen könnte bzw. umgesetzt wäre.

Gruß
Splenditnet

splenditnet · 20 Feb 2016

Buganalyse und Fixing: modfs-0.3.3 mit FW 6.36-31667-int

Hallo PeterPawn, Hallo Coco772 und andere interessierte Leser,
ich habe die gemeldete Problem von Coco772 #443 nachgestellt und bin in gleichen Fehler gelaufen.

Ausgangssitutation FB7490 mit FW 06.51 und modfs-0.3.3
Ziel: modfs-Update-Installation von FW 6.36-31667-int

Code:

# ./modfs update FRITZ.Box_7490_BETA.en-de-es-it-fr-pl.113.06.36-31667.image
SNIP
Die Modifikation 'enable system and branding selection from GUI (v0.2)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable system and branding selection from GUI (v0.2)' mit folgender Beschreibung
Auswahl des zu startenden Systems und des Brandings in der "Neustart"-Seite
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
+ language=de
+ rootdir=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root
+ mode=onrequest
+ step=precheck
+ [ 8 -eq 0 ]
+ rc=0
+ luafile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ binfile=/usr/bin/guibootmanager
+ cmdfile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/bin/guibootmanager
+ find_line
+ local line rc=0
+ eval echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
+ grep linux_fs_start /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
grep: /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua: No such file or directory
+ line=
+ [ 0 -gt 0 ]
+ rc=1
+ return 1
+ rc=1
+ [ 1 -eq 0 ]
+ find_envvar
+ local line rc=0
+ grep linux_fs_start /proc/sys/urlader/environment
+ line=linux_fs_start   1
+ [ 16 -gt 0 ]
+ rc=0
+ return 0
+ rc=0
+ [ 0 -ne 0 ]
+ rc=0
+ exit 0
Modifikation wird ausgeführt ... OK
+ language=de
+ rootdir=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root
+ mode=onrequest
+ step=install
+ [ 7 -eq 0 ]
+ rc=0
+ luafile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ binfile=/usr/bin/guibootmanager
+ cmdfile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/bin/guibootmanager
+ eval echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
+ file=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
+ sed -i /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua -e
/^local savecookie/a\
if box.post.linux_fs_start then\
local linux_fs_start = box.post.linux_fs_start\
local branding = box.post[linux_fs_start.."_branding"]\
os.execute("/usr/bin/guibootmanager switch_to "..linux_fs_start.." "..branding)\
end
/^<form action/a\
<div id="managed_reboot" class="reboot_managed">\
<?lua\
pipe = io.popen("/usr/bin/guibootmanager html_display")\
line = pipe:read("*a")\
pipe:close()\
box.out(line)\
?>\
</div>

sed: can't create temp file '/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.luaKPIZPQ': No such file or directory
+ eval echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/avm/system/reboot.lua
+ file=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/avm/system/reboot.lua
+ sed -i /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/avm/system/reboot.lua -e
/^local savecookie/a\
if box.post.linux_fs_start then\
local linux_fs_start = box.post.linux_fs_start\
local branding = box.post[linux_fs_start.."_branding"]\
os.execute("/usr/bin/guibootmanager switch_to "..linux_fs_start.." "..branding)\
end
/^<form action/a\
<div id="managed_reboot" class="reboot_managed">\
<?lua\
pipe = io.popen("/usr/bin/guibootmanager html_display")\
line = pipe:read("*a")\
pipe:close()\
box.out(line)\
?>\
</div>

sed: can't create temp file '/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/avm/system/reboot.luaMUVAKP': No such file or directory
+ install_script
+ cat
+ chown root:root /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/bin/guibootmanager
+ chmod 755 /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/bin/guibootmanager
+ rc=0
+ exit 0
Überprüfen des Erfolgs der Modifikation ... Fehler (1)
+ language=de
+ rootdir=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root
+ mode=onrequest
+ step=postcheck
+ [ 9 -eq 0 ]
+ rc=0
+ luafile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ binfile=/usr/bin/guibootmanager
+ cmdfile=/var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/bin/guibootmanager
+ find_line
+ local line rc=0
+ eval echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/$TARGET_BRANDING/system/reboot.lua
+ echo /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
+ grep linux_fs_start /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua
grep: /var/media/ftp/SanDisk-CruzerFit-01/1455986167/squashfs-root/usr/www/1und1/system/reboot.lua: No such file or directory
+ line=
+ [ 0 -gt 0 ]
+ rc=1
+ return 1
+ rc=1
+ [ 1 -eq 1 ]
+ echo Die Modifikation war nicht erfolgreich.
Die Modifikation war nicht erfolgreich.
+ rc=1
+ exit 1

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

Für mich sieht es nach Bug im Zusammenhang mit Umgebungsvariable TARGET_BRANDING bzw. TARGET_BRANDINGS aus.

Gruß
Splenditnet

EDIT: TARGET_BRANDINGS müsste eigentlich avme sein! und nicht avm, 1und1;
siehe:

Code:

# find /var/media/ftp/SanDisk-CruzerFit-01/1455987838/squashfs-root -name reboot.lua -exec ls -lad {} \;
-rwxrwxrwx    1 root     root          2819 Oct 29 10:26 /var/media/ftp/SanDisk-CruzerFit-01/1455987838/squashfs-root/usr/www/avme/reboot.lua
-rwxrwxrwx    1 root     root          2257 Oct 29 10:26 /var/media/ftp/SanDisk-CruzerFit-01/1455987838/squashfs-root/usr/www/avme/system/reboot.lua
#

EDIT2:
@PeterPawn
bitte folgende Fehlerbehebung einspielen:

Code:

# vi modfs
SNIP
modify_rootfs()
{
        local target="$1" scripts="$2" rc=0 line lines lrc filelist script donelist tmpdir flags execute
        tmpdir="$(get_temp_dir)"
        # short stop to ensure an unique temporary directory name (contains the unix time)
        sleep 1
        debug "modify_rootfs: starting, target=$target, scripts=$scripts"
        FRITZOS_VERSION="$(get_target_system_version "$target")"
        KERNEL_VERSION="$(get_target_kernel_version "$target")"
[COLOR=#ff0000]        #BRANDINGS="$(get_target_brandings)"[/COLOR]
[COLOR=#0000ff]        BRANDINGS="$(get_target_brandings "$target")"[/COLOR]
SNIP

bzw. als diff

Code:

# diff modfs.org modfs
--- modfs.org
+++ modfs
@@ -1025,7 +1025,7 @@
        debug "modify_rootfs: starting, target=$target, scripts=$scripts"
        FRITZOS_VERSION="$(get_target_system_version "$target")"
        KERNEL_VERSION="$(get_target_kernel_version "$target")"
[COLOR=#ff0000]-       BRANDINGS="$(get_target_brandings)"[/COLOR]
[COLOR=#0000ff]+       BRANDINGS="$(get_target_brandings "$target")"[/COLOR]
        BRANDING="$(get_first_branding "$BRANDINGS")"
        MODSCRIPT_ENV="$KERNEL_VERSION $FRITZOS_VERSION TARGET_BRANDINGS=\"$BRANDINGS\" TARGET_BRANDING=\"$BRANDING\""
        filelist="$tmpdir/scripts"
#

anschließend läuft modfs-0.3.3 mit FW 6.36-31667-int sauber durch

Code:

# ./modfs update FRITZ.Box_7490_BETA.en-de-es-it-fr-pl.113.06.36-31667.image
SNIP
Die Modifikation 'enable system and branding selection from GUI (v0.2)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable system and branding selection from GUI (v0.2)' mit folgender Beschreibung
Auswahl des zu startenden Systems und des Brandings in der "Neustart"-Seite
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK
Die Modifikation 'enable system and branding selection from GUI (v0.2)' wurde angewendet, Fehlercode = 0.

Update: Tippfehler behoben

koyaanisqatsi · 20 Feb 2016

Moins

Wie wird denn $TARGET_BRANDINGS ermittelt?
Ist das eine Konstante, beziehungsweise, ein Array?
Müsste zur Ermittlung und Prüfung nicht jedes mögliche Branding da ($TARGET_BRANDINGS) rein: avm, 1und1, avme
...sodaß $TARGET_BRANDING nach Prüfung auch avme enthalten kann?

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

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Urgestein

Statistik des Forums