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

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,515
Punkte für Reaktionen
846
Punkte
113
Das habe ich noch nicht probiert ... ich schaue es mir aber gerne mal an.

Hast Du zufällig noch ein Protokoll (aus "showshringbuf modfs") von einem solchen Versuch, der abstürzt? Es geht mir in erster Linie darum, dieselben Bedingungen wie beim Absturz reproduzieren zu können und die Angaben zum freien Platz in den gemounteten Partitionen zu sehen.
 

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,723
Punkte für Reaktionen
28
Punkte
48
Weiter zum 7.19-Problem geht es hier (Workaround inklusive).
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,515
Punkte für Reaktionen
846
Punkte
113
Ich finde das Problem beim Entpacken nicht und dem Protokoll nach, hat Dein "sed"-Kommando gar nichts am "modfs"-Skript geändert und es hat trotzdem - auch mit 134 MB in den beiden Werten, die Du auf 144 MB ändern wolltest - funktioniert.

Woher das "date"-Problem beim Bootmanager am Ende kommt, untersuche ich gerade - aber auch mit mäßigem Erfolg, was eine vernünftige Erklärung angeht. Vielleicht können ja andere Benutzer von "modfs" beim nächsten Mal in der Protokoll-Datei nachsehen, ob bei ihnen das Löschen des Bootmanager-Caches (wenn der im laufenden System installiert sein sollte) funktioniert oder nicht.

Wie im GitHub geschrieben, verstehe ich gar nicht, wie da ein "'date' command not found" bei herauskommen kann - ich habe noch kein System gesehen, wo das Applet nicht in der BusyBox war. Und selbst mit einem vollkommen leeren Environment sollte sich das noch aufrufen lassen, denn der Loader des Kernels sucht (quasi als letzte Instanz) auch immer noch einmal in "/bin", wenn er ein Kommando nicht finden kann - das geht sogar soweit, daß er das notfalls auch ein zweites Mal durchsucht, selbst wenn es zuvor schon in der PATH-Variablen angeführt war. Wobei das mein alter Stand ist, das überprüfe ich gleich noch einmal - steht irgendwo in den Kernel-Quellen in "fs/exec.c".

Zwar wird beim Aufruf der zweiten Shell-Instanz (absichtlich) PATH ausschließlich auf das Verzeichnis mit der zu verwendenden BusyBox eingestellt (https://github.com/PeterPawn/modfs/blob/master/modfs#L2794), aber das dient ja genau dazu, keine Applets/Kommandos/Skriptdateien mit abweichender Syntax aus Versehen aufzurufen. Vielleicht sollte ich das "gui_bootmanager"-Skript auch explizit über die aktuelle BusyBox-Shell aufrufen, damit das dann auch definitiv die statisch gelinkte Version verwendet ... wobei das Entscheidende ja nicht das statische Linken ist, sondern die Suche nach Applets, bevor es im Dateisystem mit der Suche weitergeht - und dabei sollte das "date"-Applet ja dann auch gefunden werden.

=============================================================================

EDIT:

Also mit der Version, die bisher nur im Branch "beta" im Repo steht (die ist also noch nicht als TAR-File verfügbar), kriege ich zwar auch einen Fehler beim Packen (und nicht beim Entpacken), aber der ist dadurch zu erklären, daß das neue Image inzwischen deutlich größer ist und damit mein eigenes "custom.custom"-Image, das in die Wrapper-Partition kopiert wurde (und zwar vor dem gepackten Root-Dateisystem, weil das schon zuvor durch "ATW" (add to wrapper) erfolgte), nicht mehr ausreichend Platz für das neue Image übrig läßt.

Das ist aber nur ein "Zwischenstand" ... ich lasse jetzt das Kopieren dieser Datei in die Wrapper-Partition mal aus und habe dann 16 MB mehr zur Verfügung. Ich gehe mal davon aus, daß das bei Dir (@Chatty) nicht auch das Problem war, denn ich hatte das als "Entpacken klappt nicht" verstanden und mein Problem taucht erst dann auf, wenn das fertig gepackte SquashFS-Image in die Zielpartition kopiert werden soll.

=============================================================================

EDIT2:

Also ich finde kein Problem beim Auspacken ... und ich bin absichtlich (unter "Zerstörung" der Release-Version in der anderen Partition) von einer früheren Labor-Version auf die 75160 gewechselt.

Zwar ist das AVM-Image tatsächlich außergewöhnlich groß nach dem Entpacken, weil die Dateien für die internationale und die (bisherige) deutsche Version natürlich für jedes Branding (1und1, avm, avme) einmal vorliegen und zunächst mal auch doppelt entpackt werden müssen, so daß aus der gepackten Datei "filesystem_core.squashfs" mit einer Größe von 29 MB am Ende ein Verzeichnis mit Dateien in einer Gesamtgröße von 139 MB wird. Beim späteren Packen werden dann Duplikate aber wieder automatisch zusammengefaßt und bei mir hat das produzierte RootFS-Image dann wieder eine ähnliche Größe, wie das AVM-Original.

Ich werde die Größen für die Prüfung des freien Speicherplatzes trotzdem vorerst nicht anpassen ... bei älteren Versionen reicht ja weniger freier Platz auch noch aus und ich kann/will jetzt nicht alles wegen der 07.19 umwerfen. Solange man selbst dafür sorgt, daß ausreichend Speicher im verwendeten Arbeitsverzeichnis zur Verfügung steht (notfalls setzt man eben "MODFS_WORKING_DIR" von Hand schon passend, das spart auch die Nachfrage nach dem zu verwendenden Volume, wenn es mehrere geben sollte), gibt es auch kein Problem beim Entpacken oder beim späteren Packen.

Mir fällt im Moment kein zuverlässiger Weg ein, die notwendigen Größen irgendwie "zu berechnen" ... man könnte höchstens die Größen aller Dateien aus einem "unsquashfs -lls" zusammenrechnen und dann noch die Inodes zählen, um den ungefähren Platzbedarf des entpackten Images zu ermitteln. Dazu kommen dann - je nach Modus - noch die Wrapper-Partition, der Kernel oder sogar das Download-Image ... auch wenn ich jetzt schon temporäre Dateien schnellstmöglich löschen lasse, sind das jede Menge Permutationen, die da zu berücksichtigen wären. Da fehlt mir im Moment irgendwie der Antrieb ... der funktionierende(!) Workaround ist halt die Bereitstellung von genug Platz durch den Verwender.

Ich könnte das jetzt gleich auf 256 MB hochdrehen und hoffen, daß das eine Weile reicht ... andererseits sollten (bei "update" oder "update <source_image>" beim Aufruf) normalerweise 134 MB für das Arbeitsverzeichnis gefordert werden und die sollte niemand auf seiner 7490 ohne Probleme im "tmpfs" frei haben (bei kleineren Modellen erst recht nicht, vielleicht gibt's noch bei der 3490 ein Problem, weil die weniger Features hat - die hat aber wieder keine Labor-Version) und die Benutzung des NAS-Flashs erfordert zusätzliche Environment-Settings beim Aufruf und ist ebenfalls eher "expert mode", wo man sich selbst zu helfen wissen sollte.

Solange man also dafür sorgt, daß die eigene Box genug freien Speicher auf einem nativen Linux-Dateisystem zur Verfügung hat, sollte sowohl das Entpacken als auch das Modifizieren und das spätere Packen nicht mit Speicherplatzproblemen zu kämpfen haben.

Ich packe die neue Beta jetzt noch nicht zusammen, weil ich erst noch die "modscripts" so weit anpassen will, daß die auch für 07.19 funktionieren ... einige sehen zwar gut aus, aber andere brauchen definitiv eine Anpassung an die neue OS-Struktur und dazu muß ich die jeweilige Version erst mal auf meiner Box laufen lassen, um die passenden Änderungen testen zu können.

Ich habe mal das Log meines Versuchs mit der "0.6.0-beta" (noch ohne Timestamp, weil die erst bei Einchecken gesetzt wurde) angehangen ... so ähnlich sollte das bei anderen "modfs"-Nutzern halt auch aussehen.
 

Anhänge

Zurzeit aktive Besucher

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,960
Beiträge
2,040,686
Mitglieder
353,167
Neuestes Mitglied
bgschuetze