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

[PeterPawn]

Das habe ich inhaltlich nicht komplett verstanden ... aber die Script-Dateien im "modfs"-Archiv sind eigentlich auch nur dafür gedacht, tatsächlich aus "modfs" heraus gestartet zu werden.

Normalerweise verhindere ich die direkte Ausführung in solchen Fällen durch die Angabe von "/bin/true" oder "/bin/false" im SheBang (je nachdem, ob ich einen Fehler haben will oder nicht beim direkten Aufruf) - das werde ich wohl nachholen für die Shell-Dateien im "bin"-Unterverzeichnis bzw. ich werde die SheBang-Zeilen vermutlich komplett entfernen.

Ich sollte auch nirgendwo nur "sh" im SheBang verwenden ... die Angabe des absoluten Pfades ("/bin") im SheBang sollte (solange das "/bin"-Verzeichnis und der Symlink für "true" oder "false" existiert) eigentlich nicht zu Problemen führen und aus "modfs" heraus rufe ich die inzwischen alle über "wrap_script" auf, damit man auch die Debug-Ausgabe notfalls über die Umgebungsvariable einschalten kann.

Wer die Skripte auch unabhängig von "modfs" benutzen will, der muß eben die Aufrufe aller Applets (die nicht als "noexec" bzw. "nofork" (was ein "verschärftes" "noexec" ist) deklariert sind) mit der expliziten Angabe "busybox" bzw. am besten sogar mit dem Ergebnis eines "readlink /proc/self/exe" ausführen lassen.

Es wird vermutlich unmöglich sein, mit überschaubarem Aufwand solche Skript-Dateien so zu gestalten, daß die (a) auf mehreren Modellen und (b) mit unterschiedlichen Binärdateien/OS-Versionen 1:1 laufen ... dafür gibt es Werkzeuge wie "autoconf/automake", was auf der FRITZ!Box einfach nicht sinnvoll ist. Die Skript-Dateien im "modfs"-Archiv sind dann so angepaßt, daß sie beim Aufruf aus "modfs" heraus das erwartete Ergebnis liefern ... wenn das auch mit den "unveränderten" Originaldateien machbar ist (wie beim "check_signed_image"), dann ist das schön - wenn nicht, wird es angepaßt und dann muß man auch keine Rücksicht mehr auf den Einsatz außerhalb nehmen. Ein Beispiel hier ist das "Verpacken" des "mktemp" in "juis_check" in die interne "mktmp"-Funktion - wenn ich bei "check_update" sicher sein kann, daß der Aufruf mit einer BusyBox mit "mktemp"-Applet erfolgt, dann kann ich auf den gesamten Wrapper verzichten.

Wenn das "juischeckupdate"-Skript nicht auf "xmllint" und "bash" bauen würde und die dann auf der Box ebenfalls als (am besten noch statisch gelinkte) Binaries vorliegen müßten, hätte ich die "juis_check"-Version mit "nc" gar nicht erst gebaut, da das mit den unterschiedlichen Optionen zwischen "vollen Systemen" und der Implementierung in der BusyBox auch nur Probleme bereitet, wenn da bei EOF auf STDIN sofort ein einseitiges FIN-Paket bei TCP-Verbindungen gesendet wird und der Server auf der anderen Seite dann gar nicht mehr antwortet. Aus der "juis_check" wurde dann irgendwann "check_update" ... daß das außerhalb von "modfs" liegt, ist nur der Tatsache geschuldet, daß ich das komplexe "modfs"-Skript ohnehin in kleinere Einheiten zerlegen will.

Wer das Prinzip von "check_update" auf der FRITZ!Box nachnutzen will, nimmt besser "juis_check" aus dem YourFritz-Repo (in "tools") - das braucht genau dieselben "Zutaten" (und funktioniert üblicherweise mit der AVM-BusyBox auch nicht, weil es da kein "nc" mehr gibt und das kann man auch nicht einfach "emulieren", wie ich es beim "mktemp" versuche).

Eine FRITZ!Box mit der BusyBox ist eben kein "vollwertiges Linux-System" - generell ist die Entwicklung für "embedded systems" immer ein wenig anders als für irgendein beliebiges anderes System. Schon aus der BusyBox ergeben sich da ggf. vollkommen unerwartete Effekte, angefangen bei Security-Problemen - von den fehlenden Schutzmechanismen in der FRITZ!Box (alles als "root", kein SELinux oder eine andere "mandatory access control"-Implementierung, womit ein Angreifer fast automatisch auch immer vollen "root"-Zugriff erlangt mit einem erfolgreichen Einbruch) mal vollkommen abgesehen. Hier fehlt eben fast immer die "2nd or 3rd line of defense" und so rächen sich leichte Fehler viel schneller als bei einem "ausgewachsenen" System.

- - - Aktualisiert - - -

Ich habe mal die Skript-Dateien im "bin"-Verzeichnis "nicht ausführbar" gemacht ... wer sie außerhalb von "modfs" verwenden will, muß entsprechende Vorbereitungen treffen bzw. Änderungen vornehmen.

 

[Micha0815]

Ein paar Anmerkungen zu dem Versions check - update

Sofern ich es richtig gemacht habe
./modfs update
wird nach updates gesucht und, falls etwas neueres gefunden, ungefragt erstmal heruntergeladen.

An DSL-FLAT Anschlüssen sicherlich kein Problem. An Mobilfunkanschlüssen, wo man gerne "geizen" möchte mit dem Traffic, wäre irgendein "Brake" (Abfrage-Fortfahren ja/nein) wünschenswert. Sinn ist es imho gerade Traffic zu sparen versus das komplette zip-file inkl. Recovery und Release vorab herunterzuladen und eben dann mit
./ modfs update ./Neues-Labor.image

fortzufahren.

Zudem wird nur für das aktuell aktive System gesucht.

Bsp. liegt in der inaktiven Partition ein 6.60er Release und man hat gerade eine Labor 41137 am laufen, wird die aktuelle 41222 gefunden, heruntergeladen und in die inaktive Partition geschrieben, wo eigentlich die zu erhaltende 6.60er liegt.

Umgekehrt, gestartet mit 6.60, wird nix gefunden und abgebrochen.

Sicherlich kann man irgendwo in einem script diese jason... url händisch eintragen oder ein separates Script dazu nutzen. Das muss man halt erstmal beherrschen

Ansonsten läuft es vorzüglich.

LG und nurmal als kleine Wunschliste, sofern einfach umsetzbar. Ob man überhaupt die Versionsnummer der inaktiven Partition abfragen kann, ohne diese geladen/gestartet zu haben übersteigt meinen Horizont.

 

[PeterPawn]

Man kann die andere Partition durchaus abfragen (wenn das System dort paßt mit dem SquashFS-Format) ... ich sehe bloß immer kompliziertere Aufruf-Parameter auf die Benutzer zukommen.

Ziel war es hier, die Benutzung mit Labor-Versionen zu vereinfachen - also in erster Linie das "modfs update" universeller zu machen, wo bisher nur auf dem FTP-Server nach neuen Versionen gesucht werden konnte und das geht für Labor-Versionen schon mal prinzipiell nicht.

Bei dem geschilderten Szenario würde es m.E. die Bandbreite am meisten schonen (der Download in "modfs" ist auch nur temporär und wird normalerweise am Ende "entsorgt", max. das SquashFS-Image läßt sich speichern für wiederholte Anwendung), wenn man vorher von Hand die Update-Abfrage macht (das kann "juis_check" auch auf der Box, solange man irgendwo ein "nc" hat) und ein dabei gefundenes Update selbst per "wget" lädt - das kommt dann (wenn es das "wget" der BusyBox ist) auch mit der Syntax mit Benutzernamen und Kennwort in der URI klar und beherrscht auch beide Protokolle (http / ftp), die AVM derzeit verwendet.

Den zusätzlichen Traffic-Overhead durch das ZIP-File mit stets derselben Recovery-Version vermeidet man auf diesem Weg ebenfalls und das Einbetten des "juis_check" in ein zusätzliches Skript mit der Abfrage, ob wirklich geladen werden soll, bevor das "wget" letztlich ausgeführt wird, ist auch problemlos möglich und dabei kann man dann auch noch dafür sorgen, daß man wirklich die Versionsnummer aus der inaktiven Partition verwendet (bzw. eben als Parameter angeben, welche Vergleichsversion verwendet werden soll).

Da gibt es m.E. zuviele Permutationen, wie jemand die variablen Parameter kombinieren könnte, als daß diese Frage in "modfs" irgendwie geklärt werden könnte. Da ist ein anderes Skript dann die bessere Lösung und das dabei geladene Image kann dann wieder mit "./modfs update <imagedatei>" verwendet werden. Damit ist dann auch der Benutzer dafür verantwortlich, das Image irgendwo so zu sichern, daß der Download nicht mehrfach ausgeführt werden muß.

Ich verstehe das Anliegen ... aber der Einsatzfall ist m.E. nicht der typische und damit sollte das nicht in "modfs" passieren, sondern in einem zusätzlichen Skript. Wenn ich lustig bin, kann es passieren, daß ich noch ein entsprechendes Skript baue ... ich trage mich ohnehin mit dem Gedanken, den "gui_bootmanager" um eine Anzeige zu erweitern, ob für eine Version in einer der beiden Partitionen ein Update verfügbar ist oder nicht. Bei AVM funktioniert das ganz gut, aber eben auch nur für die gerade aktive Partition. Die Idee dahinter ist es, irgendwann an dem Punkt anzukommen, wo an die Stelle so eines Neustarts für eine alte Version das (automatische) Update mit "modfs" tritt und vor dem Neustart "schnell noch" (angesichts von ca. 10 Minuten etwas euphemistisch) eine Aktualisierung zu machen.

Ansonsten will ich eigentlich eher von weiteren Abfragen beim Benutzer wegkommen ... die meisten dürften immer wieder dieselben "Antworten" auf die Abfragen von "modfs" geben und da macht dann die weitere Automatisierung (ein Ansatz war ja damals schon das "custom_modscripts"-File, damit man nicht jedesmal erst die Rechte anpassen oder dumme Fragen beantworten muß) mehr Sinn. Dem steht natürlich der weitere Ausbau des "Frage/Antwort-Spiels" diametral entgegen.

 

[Micha0815]

Danke

für die Erläuterungen a la Roadmap. Der Thread soll ja der Fehlerbehebung dienen respektive Neuerungen Deinerseits. Mit "Wunschlisten" wollte ich den wahrlich nicht zumüllen.

Mit Deinem Einverständnis könnte man ja ein neues Thema eröffnen ... "Modfs und wie setzt ihr es ein und wo hakt`s" ... wo Wünsche und Alltagssorgen der kleinen Leute einfliessen könnten ... falls nicht gleich ein "Bademeister" angerannt kommt und auf das Nichtschwimmerbecken verweist

OT-Zitat gelöscht

...
@ hab... ist einfach Über .
wenn dich fragen hier stören dann ignorier sie doch oder antworte vernünftig.
Bademeister gehören ins schwimmbad.

Im stillen Kämmerlein habe ich mir schon mal ein kleines Kochrezept -Anfängertauglich mit möglichst wenig Konsolen-Befehlen- zurechtgelegt. Falls ich es mit der aktuellen modfs-Version hin+her getestet habe, werde ich es mal posten (Das Theater wie seinerzeit mit Eisbärin tue ich mir nicht nochmals an).

Persönlich -als ambitionierter Anfänger- finde ich einfach das switchen zw. einer Release und Labor, jeweils mit Console einfach genial.

Was ich bis dato nicht ganz begreife, weshalb beim switchen ein DECT200 zwar seine "Anmeldung" behält wie auch DECT-Phones, nur ein Teil der Einstellungen e.g. Namensgebung individuell und die Zeitschaltung verloren gehen? (Falls dazu showsringbuf oder Debug-Protokolle hilfreich ... erbitte ich eine kurze Anweisung). Falls dies ein normales Verhalten, muss man dem wohl auch nicht nachgehen.

Ok ich nutze hier die Zeitschaltung nur für einen Boiler zw. Nachtstromaufheizung (eine kalte Dusche im heissen Sommer war der Erfahrungswert). Andere User ggfs. mit Gruppenschaltung etc. und wichtigeren Schaltungsaufgaben könnten not amused sein, falls übersehen. Zudem denke ich über einen DECT-ULE-Thermostaten nach -die Heizperiode beginnt wohl demnächst- wo eine Zeitprofilübernahme beim switchen schon mehr als sinnvoll wäre.

Der Ansatz, ein FW-Update via GUI auf der gestarteten Partition ohne Umschweife anzustossen, ist natürlich der BRINGER.

Hier erkenne ich leider nur die Main-Revision eg. 113.06.60 vs 113.06.69 aber nicht die interne Subversion. Falls der Platz in der GUI dazu nicht reicht ... geschenkt.

LG und sorry, falls, diese meine Anmerkungen hier, als Individualwünsche rüberkommen, die nicht dem Mainstream entsprechen.

- - - Aktualisiert - - -

Nachtrag: via #1 lese ich etwas von dect
https://github.com/PeterPawn/modfs/blob/master/modscripts/dectcmds.modscript
Vollumfängliches Begreifen eine andere Gewichtsklasse

Ein Edit bzgl. 0.4.0 wäre imho auch nicht verkehrt beizeiten?

Und wie gerade bemerkt lt. #1, ist das "Baby" ja dieser Tage zwei Jahre alt geworden. "Happy Birthday" an den Vater.
Die Dauer zw. "Zeugung und Geburt" ... bei human Beings eher bekannt :mrgreen:

 

[PeterPawn]

"dectcmds" bietet die Möglichkeit, mit einem AVM-DECT-Telefon über den Mediaplayer (durch "Ansehen" eines Bildes) eigene Aktionen/Kommandos auszuführen.

Es ist zwar am Beginn etwas gewöhnungsbedürftig, aber während man bei AHA ja Steckdosen "schalten" kann, gibt es (bisher?) keine Möglichkeit, andere Aktionen per DECT-MT auszulösen. Zwar ist die Navigation zum Mediaplayer und zum richtigen Eintrag "zu erlernen", dafür können mit unterschiedlichen angezeigten Bildern auch Erfolg und Fehler oder aktueller Zustand signalisiert werden.

Das ginge vom Einschalten der generellen Klingelsperre a la "nacht.lua" bis zu so ziemlich jedem komplexeren Skript, was man sich vorstellen kann. Es ist einfach ein "Trigger" für die Ausführung eines beliebigen Skripts per Telefon-Menü - das Skript darf dann halt keine weitere "Interaktion" erfordern.

Die Änderung in #1 wird sicherlich demnächst noch kommen.

- - - Aktualisiert - - -

Neuer Build ist online, netterweise brauchte ja das verwendete OpenSSL 1.0.2i gleich das nächste Update.

 

[Master SaMMy]

Mit der [FONT=&amp]06.69-41438 und modfs bootet die box nicht mehr richtig. Und die Power LED leuchtet dauerhaft.
habe vor dem testen wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar xv auch gemacht also aktuellste version benutzt

weiterer fehler ist das hier

Soll die Modifikation 'enable telnet daemon' mit folgender Beschreibung
Busybox-Symlink für den Telnet-Daemon erstellen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.

Die Modifikation 'enable telnet daemon' wurde angewendet, Fehlercode = 1.

[/FONT]

 

[PeterPawn]

Wie kann das ein (echter!) Fehler sein?

Bei den "Inhouse-Versionen" ist bekanntermaßen auch der Symlink für den Telnet-Daemon bereits vorhanden ... und es steht doch deutlich da: "... oder ist nicht erforderlich.".

Das gesamte "modfs"-Paket war und ist nicht dafür gedacht, mit einer der inoffiziellen Versiionen benutzt zu werden. Es mag sein, daß es ab und an funktioniert - aber die Fluktuation bei diesen Versionen ist nun so groß, daß ich nicht im Traum daran denke, da irgendwie eine Anpassung vorzunehmen, solange so etwas nicht bei einer Release-Version (bei einer Labor-Version lasse ich mich vielleicht noch breitschlagen) auftritt.

Hier ist ja nicht einmal klar, welche der "modfs"-Änderungen nun überhaupt ausgeführt wurden.

 

[Micha0815]

Sofern die Frage erlaubt?

Als Anfänger fällt mir das Bestätigungs-Code-Problem auf die Füsse zwecks Abschaltung. Gibt es eine Möglichkeit, dies an der Console -sofern man Telnet-Dämon im Ablauf des Scripts aktiviert hat- nachträglich zu Korrigieren/Abzuschalten. Trotz redlicher Bemühung finde ich dazu nix.

Für einen freundlichen Hinweis respektive der grundsätzlichen Überlegung seitens PeterPawns, dies in den Standard-Abfrage-Modus des Scripts u.U. einzubauen (falls nur eine kleine Fingerübung?) bedanke ich mich im Voraus.

LG und falls meine Anfrage -es ist ja kein modfs-Wunschkonzert-Thread hier- auf Gegenwind stösst, lösche ich es sofort!

 

[PeterPawn]

Zwei Möglichkeiten der Abschaltung ... Editieren der ar7.cfg und Ändern von

$ grep two_factor /var/flash/ar7.cfg
        two_factor_auth_enabled = yes;

auf "no" (abgeschaltet) oder "yes" (eingeschaltet).

Alternative ist das Verwenden von "ctlmgr_ctl" (oder "set.lua") mit folgender Syntax:

$ grep two_factor /var/flash/ar7.cfg
        two_factor_auth_enabled = no;
$ ctlmgr_ctl w boxusers settings/twofactor_auth_enabled 1
1
$ grep two_factor /var/flash/ar7.cfg
        two_factor_auth_enabled = yes;
$ ctlmgr_ctl w boxusers settings/twofactor_auth_enabled 0
0
$ grep two_factor /var/flash/ar7.cfg
        two_factor_auth_enabled = no;

Wo da jetzt "modfs" sinnvoll anwendbar wäre bzw. was da gepatcht werden sollte, verstehe ich bis hier noch nicht ... das müßte also noch etwas ausführlicher erklärt werden.

Bei der Abschaltung über Kommandos braucht es keine Bestätigung, beim Import einer geänderten "ar7.cfg" gilt halt die aktuelle Einstellung und ich sehe auch nicht so richtig, was man da machen könnte oder sollte.

Ein Patch, um das generell abzuschalten, müßte sich auf die Stellen in den Lua-Dateien stürzen, wo es verwendet wird.

Da warte ich lieber, bis AVM das fertig hat ... sollte es bei der Code-Abfrage bei Faxversand bleiben, wird es einen Patch geben - schon damit nicht der Faxversand am Ende der Grund ist, warum die Leute das generell abschalten. Ich hoffe immer noch darauf, daß AVM da feiner granulierte Einstellungen - z.B. die Auswahl, was per Code-Abfrage zu schützen wäre - zulassen und einbauen wird.

 

[Micha0815]

Danke für die Erläuterung

... Ich hoffe immer noch darauf, daß AVM da feiner granulierte Einstellungen - z.B. die Auswahl, was per Code-Abfrage zu schützen wäre - zulassen und einbauen wird.

und bekanntlich stirbt die Hoffnung zuletzt.

LG

 

[Freem]

Guten tag

Habe mir die 7490 geholt

Hab mir die Anleitung von eisberin oder wie die heisst genau durch gelesen

Hab ein downgrade auf 6.24 gemacht dann habe ich telnet aktiviert und habe dann die Anleitung befolgt mit dem modfs und 6.51 Image aber beim reboot leuchtet nur die Power Leuchte und nichts passiert

 

[PeterPawn]

Ist das ein Statement oder eine Frage oder gar die Bitte um Hilfe? Was erwartest Du jetzt genau?

Es ist sicherlich unnötig, hier erneut festzuhalten, daß man am Ende mehr Fragen als Antworten aus #912 ableiten muß. Das geht dabei los, warum es die 06.51 sein soll, wenn es doch die 06.60 als letztes Release gibt und endet irgendwo jenseits des Protokolls von "modfs".

Leider zeigt es sich ja immer wieder mal, daß selbst das genaue Lesen einer Anleitung noch kein Garant für den Erfolg ist ... man muß die dann auch noch genau einhalten und ggf. bei zwischenzeitlich auftretenden Fehlern die als solche erkennen und entsprechend reagieren - das ist ja keine "black box", wo man am Anfang ein Kommando "einkippt" und dann am Ende nur das Ergebnis (Box startet nicht) beurteilt.

 

[Micha0815]

...

Hab ein downgrade auf 6.24 gemacht dann habe ich telnet aktiviert und habe dann die Anleitung befolgt mit dem modfs und 6.51 Image aber beim reboot leuchtet nur die Power Leuchte und nichts passiert

Als fauler Anfänger habe ich mir neulich auch die 6.24-Recovery aufgespielt, da das "modfs-starter-Gezumpele" zu aufwändig.

Das klappt ganz gut, nur musst Du Dich von 6.24 im Pilgerschritt "hochhangeln".

Ich hatte dazu einen User mit Admin-Rechten auf der FB eingerichtet und dem Vollzugriff auf FTP-Medien gegeben. Einen ext3 formatierten Speicherstick (mit Mini-Tool-Partitionswizzard) erstellt und dort die FWs in das zuvor via telnet erstellte Verzeichnis unter /var/media/ftp/"stickverzeichnis" draufkopiert mit Totalcommander (Option versteckte Dateien aktiviert und FTP-Zugang eingerichtet für User) dann ist es einfach zu kopieren per drag+drop. Wichtig den kopierten FW-Dateien und auch allen Unterverzeichnissen insbesonders VR9 von modfs die 777 als Rechte zu verpassen. Ich hoffe das hilft weiter. Bei Gelegenheit poste ich mal meinen internen Spickzettel ... wo die Linux-Konsolen-Experten dann sicherlich die Nase rümpfen werden. Who cares :lol: Recht sinnvoll sich unter W10 die Linux-Bash einzurichten. Manche Codezeile lässt sich da einfacher via copy und paste übernehmen als über "cmd".
Beim abtippern übersehe ich oft Leerzeichen oder halte ein grosses "O" für eine "Null" 0 oder was casesensitives oder Linux-spezifsche Sonderzeichen wie "|" (kein kleines L oder grosses "I"), was dann immer mehrere Anläufe braucht.
LG

P.S.: Wegen des noexec-Problems klappt das nur bis 6.60 FW.

- - - Aktualisiert - - -

[Edit Novize: Bitte beim Thema bleiben! OT-Teil gelöscht]

 

[Pokemon20021]

und auch allen Unterverzeichnissen insbesonders VR9 von modfs die 777 als Rechte zu verpassen.

da verstehe ich den Sinn nicht;
auch ist mir nicht klar wozu man einen Totalcommander brauchen soll;
das ist doch irgendwie umständlich;

warum gibst Du nicht einfach die Befehle im Putty via Telnet-Zugang per Copy&Paste ein ???

mkdir modfs-0.4.0-250920161556; 
cd modfs-0.4.0-250920161556; 
wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x;
./modfs update

siehe auch "Herstellerempfehlung" in #1

 

[Micha0815]

da verstehe ich den Sinn nicht;
auch ist mir nicht klar wozu man einen Totalcommander brauchen soll;
das ist doch irgendwie umständlich;

Ich komme damit halt schneller und besser zurecht, kann mir die ftp-Zugangsdaten für div. FBs und STBs übersichtlich Speichern und bei Bedarf aufrufen. Schnell Kopieren entpacken usw.

warum gibst Du nicht einfach die Befehle im Putty via Telnet-Zugang per Copy&Paste ein ???

mkdir modfs-0.4.0-250920161556; 
cd modfs-0.4.0-250920161556; 
wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x;
./modfs update

siehe auch "Herstellerempfehlung" in #1

Dies hatte ich heute auf einer IP-Client-FB7490 getestet -hier mit der aktuellen modfs-version 0.4.0-181020160333 von einer gestarteten 06.60FW mit/zu der Labor-41670 FW, die vermeintlich fehlerfrei abgearbeitet wurde!
(ok die sonst harmlose Fehlermeldung

Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'own files' mit folgender Beschreibung
Programme hinzufügen/ersetzen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... nicht unterstützt
Modifikation wird ausgeführt ... Fehler (3)
Unable to find binaries file 'files/binaries_113_3.10.73.tgz' to be unpacked...

mal aussenvor), nur die FB in einen NoGo-Zustand nach reboot verbrachte. Kein WLAN-Access möglich (Taster ohne Funktion) und auch kein LAN-Zugang mehr möglich unter bekannten IP-Konstellationen. Erst mühsam über adam2 und switchen und abarbeiten über eine ältere modfs-Version 0.3.5-020820162237 lief es -auch im Nachgang auf einer 2ten FB- durch.

Sollte Freem in #912 genau dies beschrieben haben, so kann ich nur bestätigen, dass ausser einer leuchtenden POWER LED die FB sich tot stellt?

Besser man greift auf eine ältere modfs-version zurück, und packt sich die gewünschte FW manuell nach var/media/ftp/...

und arbeitet mit

./modfs update ./wunsch.image

Vorteil offline zu modden, es braucht keine I-Net-Verbindung und man hat den Überblick, falls mehrere FBs im Heimnetz und weiss welche FW verwandt wird.

LG

 

[Pokemon20021]

./modfs update ./wunsch.image

Vorteil offline zu modden, es braucht keine I-Net-Verbindung

genau das ist doch ein Nachteil, unnötiger Aufwand.

und man hat den Überblick, falls mehrere FBs im Heimnetz und weiss welche FW verwandt wird.

das verstehe ich ehrlich auch nicht,
Du verbindest Dich doch am Ende genau so per telnet, SIAB oder dropbear mit der Box;
und "modfs update" sagt Dir doch welche FW gefunden wurde;

wie soll man dann nicht mehr wissen, um welche Box und FW es handelt ?
ich hoffe ich kann die Vorurteile aufdecken ...

 

[PeterPawn]

Also bei mir funktioniert das Online-Update auf die 41670 (von einer 41556 aus) problemlos ... und zwar auch mit der aktuellen Version von "modfs".

2016-10-23 15:50:48.391 - modfs: starting modfs script version [COLOR="#008000"]0.4.0-181020160333[/COLOR]
2016-10-23 15:50:48.409 - modfs: script=./modfs
2016-10-23 15:50:48.430 - modfs: using language de
2016-10-23 15:50:48.449 - modfs: PATH=/var/media/ftp/modfs/bin/185
2016-10-23 15:50:48.467 - modfs: SHELL=/var/run/modfs/sh
2016-10-23 15:50:48.486 - modfs: SHLVL=6
2016-10-23 15:50:48.517 - modfs: BusyBox: BusyBox v1.24.2 (2016-09-24 17:17:47 CEST) multi-call binary.
2016-10-23 15:50:48.546 - modfs: using temporary file list from /var/tmp/19358_filelist_1477230648
2016-10-23 15:50:48.565 - modfs: cleanup trap set
2016-10-23 15:50:48.585 - modfs: invoked with: update
2016-10-23 15:50:48.606 - modfs: noversioncheck=1, update_file_provided=0
[...]
2016-10-23 15:50:53.279 - progress: mode=1, msg=Download eines Firmware-Images für Version 113.06.69-41670 vom Server des Herstellers ...
2016-10-23 15:50:53.306 - modfs: download directory=/var/tmp/1477230653
2016-10-23 15:50:53.325 - download_firmware: target=/var/tmp/1477230653/firmware.image, source=ftp://jason:[email protected]/labor/7490/FRITZ.Box_7490_LabBETA.113.06.69-41670.image
2016-10-23 15:51:08.479 - download_firmware: 26951680 bytes downloaded
2016-10-23 15:51:08.499 - download_firmware: exiting, rc=0
[...]

und auch das dabei entstehende System startet ohne die geringsten Beschwerden.

Das macht ein tatsächliches Problem in der "modfs"-Version schon mal unwahrscheinlicher ... die letzten Änderungen ("Nachtschaltung" wiedererwecken und ein paar Änderungen in Skriptdateien - meist kleine Korrekturen) haben wohl eher nicht dazu geführt, daß das neue Paket nun in Gänze nicht mehr funktioniert.

Ich habe zwar die Skript-Dateien von den "echten Binaries" getrennt ... aber das sollte keine sichtbaren Auswirkungen haben. Ich will mir nur etwas einfallen lassen, wie "modfs" auch ohne große zusätzliche Vorbereitungen mit dem "noexec"-Flag beim Mounten für USB-Volumes umgehen kann, wenn jemand das Paket nur einmal laden und im Anschluß auf den USB-Stick entpacken will. Ein erster Schritt ist es da schon mal, die Skript-Dateien (die kein "x"-Flag brauchen, wenn sie mit "sh <filename>" aufgerufen werden) zu separieren.

Ob man nun das Update-Image direkt laden läßt oder es vorher selbst irgendwo ablegt, ist reine Geschmacksfrage ... ich habe ohnehin noch ein gesondertes Firmware-Archiv und da liegt die Datei immer als erstes - dann kann ich sie auch von dort verwenden. Braucht man keine weitere Kopie, nimmt der explizite Download nur Platz irgendwo weg. Aber das ist eben alles von der eigenen Umgebung abhängig ... nicht zuletzt deshalb bietet das Skript ja mehrere Möglichkeiten an und trotzdem sollten die dann auch alle funktionieren.

An der 41670 oder der neuen "modfs"-Version sollte es aber eher nicht liegen, wenn da eine Box nach der Modifikation nicht starten will. Wenn das reproduzierbar sein sollte, braucht man ohnehin das "modfs"-Protokoll und (wenn da nichts zu sehen ist) einen Dump der erzeugten Kernelpartition und ein Tarball des erzeugten Wrapper-Dateisystems, wenn man da nach einem Fehler suchen will.

 

[Micha0815]

Ich habe heute wenig Zeit und nur mal als ersten Hinweis. Das aktuelle modfs läuft durch, allerdings ohne Einzelabfrage und scheint zu vergessen, das modifizierte image in die jeweils inaktive mtd* zu schreiben?
Imho sollte dies bei einer gestarteten Laborversion das Release 6.60 in der inaktiven überschreiben? siehe Anhang. U.U. mag modfs nicht zwei identische FW-Versionen?

LG

 

[Pokemon20021]

nur die FB in einen NoGo-Zustand nach reboot verbrachte

Frage: kann es sein, dass Du das Branding z.B. von "avm" nach "avme" gleichzeitig mit umflashen wolltest ?
dies würde dann den nachfolgenden Bootloop nach Anwendung von modfs erklären.

Ansonsten am Besten den modfs debuglogs einstellen.

 

[Micha0815]

Nein jeweils avm-Branding. Den Fehler hatte ich vor einiger Zeit mal gemacht, als auf beiden Partitionen unterschiedliche FWs gemoddet wurden und ich in der Konsole den reboot anstiess, statt über die GUI mit entsprechendem Branding.

Ein auch nicht "kleines" Problem ist, dass angeschlossene DECT200 stets den Namen "vergessen" - dass ist undramatisch- nur muss stets die Zeitschaltung neu eingestellt/aktiviert werden. Dies ist mir auf einer entfernten VPN-Box (UMTS-Verbindung via E3131), die seit 1,5Wochen hakt) zum Verhängnis geworden. Dies ist kein modfs-Problem, nur wurmt es, dass DECT-Phones und auch DECT200 die Anmeldung schaffen, die Phones auch "alles" behalten, nur die DECT200 ihre Namen vergessen und den zuvor eingestellten/aktivierten "Zeitschaltungsmodus". Wirklich mühsam könnte dies für Leute sein, die neben einigen DECT200 auch noch DECT-ULE Thermostaten mit entsprechend aufwändigen Schaltszenarien am Start haben?
LG

- - - Aktualisiert - - -

Hier mal der Log sofern relevant? Gestartes System/aktiv 06.69-41670 inaktiv 06.60-3... zu modden (und bitte zu schreiben) als Basis für die inaktive Partition 06.69-41566.

micha@MICHA0815X64:~$ telnet 192.168.177.2
Trying 192.168.177.2...
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41670

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/modfs3/41556.image' wird als Quelle für die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... OK
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/1477248950/squashfs-root


Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... nicht unterstützt
Modifikation wird ausgeführt ... Fehler (3)
Unable to find binaries file 'files/binaries_113_3.10.73.tgz' to be unpacked.

Die Modifikation 'own files' wurde angewendet, Fehlercode = 3.

Die Modifikation 'install dectcmds hook' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'install dectcmds hook' wurde angewendet, Fehlercode = 0.

Die Modifikation 'create edit_rcuser command' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'create edit_rcuser command' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable system and branding selection from GUI (v0.2)' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Ü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.

Die Modifikation 'customize the original firmware with extension packages' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'customize the original firmware with extension packages' wurde angewendet, Fehlercode = 0.

Die Modifikation 'customize the original firmware with extension packages' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'customize the original firmware with extension packages' wurde angewendet, Fehlercode = 0.

Die Modifikation 'unhide MAC by default' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/net/net_overview.js
patching file usr/www/1und1/net/net_overview.js
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'unhide MAC by default' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable telnet daemon' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable telnet daemon' wurde angewendet, Fehlercode = 0.

Die Modifikation 'add led display tab' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/system/led_display.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/system/led_display.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add led display tab' wurde angewendet, Fehlercode = 0.

Die Modifikation 'mount by label' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'mount by label' wurde angewendet, Fehlercode = 0.

Die Modifikation 'add night time control to system menu' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/avm/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
patching file usr/www/1und1/menus/menu_data.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add night time control to system menu' wurde angewendet, Fehlercode = 0.

Die Modifikation 'show phone number names' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/lua/foncalls.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'show phone number names' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable custom profile extension' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable custom profile extension' wurde angewendet, Fehlercode = 0.

Die Modifikation 'enable rc.user execution' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'enable rc.user execution' wurde angewendet, Fehlercode = 0.

Die Modifikation 'show device name instead of type on GUI' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/content.lua
patching file usr/www/avm/content.lua
patching file usr/www/avm/content.lua
patching file usr/www/1und1/content.lua
patching file usr/www/1und1/content.lua
patching file usr/www/1und1/content.lua
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'show device name instead of type on GUI' wurde angewendet, Fehlercode = 0.

Die Modifikation 'add VPN summary on overview page' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file usr/www/avm/home/home.lua
patching file usr/www/avm/home/home.lua
patching file usr/www/avm/home/home.js
patching file usr/www/avm/home/home.js
patching file usr/www/avm/home/home.js
patching file usr/www/1und1/home/home.lua
patching file usr/www/1und1/home/home.lua
patching file usr/www/1und1/home/home.js
patching file usr/www/1und1/home/home.js
patching file usr/www/1und1/home/home.js
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'add VPN summary on overview page' wurde angewendet, Fehlercode = 0.

Die Modifikation 'remove affected swap space before stopping USB devices' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
patching file etc/hotplug/storage
patching file etc/hotplug/usb.pandu
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'remove affected swap space before stopping USB devices' wurde angewendet, Fehlercode = 0.

Die Modifikation 'modscript template' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Language=de
rootdir=/var/media/ftp/1477248950/squashfs-root
mode=auto
step=precheck
TARGET_KERNEL_VERSION=3.10.73
TARGET_SYSTEM_VERSION=113.06.69
TARGET_SYSTEM_SUBVERSION=-41556
TARGET_SYSTEM_DATE=10.10.2016 16:51:40
TARGET_BRANDINGS=avm 1und1
TARGET_BRANDING=avm
Modifikation wird ausgeführt ... OK
Language=de
rootdir=/var/media/ftp/1477248950/squashfs-root
mode=auto
step=install
TARGET_KERNEL_VERSION=3.10.73
TARGET_SYSTEM_VERSION=113.06.69
TARGET_SYSTEM_SUBVERSION=-41556
TARGET_SYSTEM_DATE=10.10.2016 16:51:40
TARGET_BRANDINGS=avm 1und1
TARGET_BRANDING=avm
Überprüfen des Erfolgs der Modifikation ... OK
Language=de
rootdir=/var/media/ftp/1477248950/squashfs-root
mode=auto
step=postcheck
TARGET_KERNEL_VERSION=3.10.73
TARGET_SYSTEM_VERSION=113.06.69
TARGET_SYSTEM_SUBVERSION=-41556
TARGET_SYSTEM_DATE=10.10.2016 16:51:40
TARGET_BRANDINGS=avm 1und1
TARGET_BRANDING=avm

Die Modifikation 'modscript template' wurde angewendet, Fehlercode = 0.

Die Modifikation 'install YourFritz hooks' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
[COLOR=#ff0000]cp: can't stat 'files/busybox': No such file or directory[/COLOR]
Überprüfen des Erfolgs der Modifikation ... OK

Die Modifikation 'install YourFritz hooks' wurde angewendet, Fehlercode = 0.
#

Wohl sauber abgearbeitet ... nur imho halt nicht in die alternative Partition geschrieben?

Nachtrag: Oder hakt es erneut an der busybox und der Version/config?