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

Fehlt halt die Unterstützung für SQFS4 (bzw. den ext2-Wrapper) der 06.35, wenn da schon 06.35 auf der Box läuft.

Von 06.2x aus auf 06.35 funktioniert ja auch (mit der neueren Version).

Ich bin dran (habe nur Deine PN nicht beantwortet, weil es noch nichts gab) ... wobei "habe es auf dem Zettel" wahrscheinlich präziser wäre - im Moment fehlt mir etwas der Antrieb, da ich immer wieder auf 06.24 zurück kann, wenn ich neue Sachen für das Update in Richtung 06.35 testen will.

Ich versuche mich zusammenzureißen und das noch zu einem halbwegs vernünftigen Abschluß zu bringen. Aber das wird dann auch das letzte in "shell" sein ... das braucht dringend ein rewrite auf etwas Sinnvolles, 2.700 Zeilen Shell sind einfach zu unhandlich.

Ja, entweder beim DOCSIS-Telnet über S44-hostname aus "compose" und "decompose" kopieren, da wird beim "compose" die Prüfsumme auch berechnet.

Aber wenn man ohnehin mit einem Editor an der Export-Datei ändern will (und nicht automatisch, was der eigentliche Einsatzzweck für die Bash-Skripte wäre), kann man ja auch gleich den FBEditor in einer passenden Version verwenden ... der hat hier ein eigenes Unterforum.

Ich habe etwas mit BurningCrash getestet und mich anschließend entschlossen, eine komplette Protokollierung in eine Datei in das Skript einzubauen, um bei Fehlern besser reagieren zu können. Allerdings erfolgt die Protokollierung in eine temporäre Datei (mit den AVM-Tools für die Ringpuffer-Protokollierung) und das nutzt natürlich bei solchen kompletten Restarts eher nichts.

Wobei ich immer noch nicht weiß, wie diese bei Euch zustande kommen sollen ... das kann fast nur "memory pressure" sein und das sollte nach dem Neustart in der "crash.log" stehen. Wenn es etwas anderes ist, sollte das trotzdem in der crash.log stehen, wenn das nicht ein absoluter panischer Neustart ist.

Das neue Skript ist tatsächlich in Arbeit, auch wenn sich jetzt eine Woche lang nichts Neues für die Öffentlichkeit getan hat.

rogosch schrieb:

Oder gibt es die Datei auch noch an anderer Stelle?

Zum Vergrößern anklicken....

Wenn Du das automatische Versenden von Fehlerberichten an AVM aktiviert hast, wird die wohl seit neuestem gelöscht, wenn der Bericht erstellt wurde.

Kannst Du mal das Skript mit "sh -x modfs ..." laufen lassen und die letzten Zeilen vor dem Reboot posten? Ich habe nicht mal eine Vorstellung, wo das so abstürzen will, daß es zum Reboot kommt.

Bitte auch noch mal angeben, von wo nach wo Du willst, ob meine Erinnerung 7362SL stimmt und wie Du den Aufruf machst.

So, es gibt jetzt eine neue Version ... die Szenarien, in denen ich sie bei mir erfolgreich getestet habe, stehen in #1.

Dabei habe ich immer eine USB-HDD mit einem nativen Linux-Filesystem verwendet (mein NAND-FS ist absichtlich bis auf 70 MB freien Speicher gefüllt), den gesamten Teil mit der Container-Datei auf einem FAT32- oder NTFS-Volume habe ich nicht erneut getestet.

Auch handelte es sich bei mir immer um die 7490, andere Modelle kann ich nicht selbst testen. Wenn jemand erfolgreich ein solches Gerät modifiziert hat (mit/für 06.30, das dürfte derzeit der häufigste "use case" sein), wäre ein kurzer Bericht nett, ich nehme dann in #1 noch eine Liste (bzw. Verweise auf) diese(r) Berichte auf.

Um die Fehlersuche etwas zu vereinfachen, habe ich eine Protokollierung in das Skript eingebaut, die die AVM-Tools zur Ringpuffer-Protokollierung verwendet.

Aktiviert wird das Debug-Logging über die Umgebungsvariable MODFS_DEBUG. Hat diese den Wert "1", wird in einen Ringpuffer von 8 KB Größe mit dem (Datei-)Namen des Skripts protokolliert. Der Puffer läßt sich über die zusätzliche Variable "MODFS_BUFSIZE=n" vergrößern (Angabe in KB), wobei ich Werte > 64 nicht getestet habe. Ein Aufruf mit Debug-Ausgabe könnte also so aussehen:
Tritt dann ein Fehler auf, kann man sich mit
diese Protokolldatei anzeigen lassen, sie über eine entsprechende Umleitung
in einer Datei abspeichern und dann einer Fehlermeldung hinzufügen. Diese Protokollierung hilft natürlich bei spontanem Reboot einer Box auch nicht, aber da sehe ich die Ursache auch eher in allgemeinem Ressourcenmangel als in einem bestimmten Verhalten oder einer bestimmten Aktion des Skripts.

Ich hoffe auf Verständnis, wenn ich Fragen zu Problemen nur noch beantworte, wenn auch das entsprechende Protokoll als Anhang (bitte wirklich als Anhang und nicht in Code-Tags, das liest sich einfach lokal im Editor besser) in der Fehlermeldung enthalten ist (solange das Problem nicht die Protokollierung selbst betrifft).

Da es mir auf Dauer auch zu albern ist, weiterhin mit eigenen squashfs-tools in diesem Zusammenhang zu hantieren und inzwischen in Freetz das Erstellen der Tools für SquashFS4 und die Abarbeitung auf der FRITZ!Box ebenfalls enthalten ist, habe ich meine eigenen Versionen durch mit dem Freetz-Trunk erstellte ersetzt in der veröffentlichten Version. Damit sind die zur Übersetzung der Binärdateien im Archiv notwendigen Quelltexte im Freetz-Trunk zu finden. Solange man diese Tools nicht in ein Firmware-Image mit einbauen will, spielt auch die Größe der komplett statisch gelinkten Binaries für SquashFS4 keine entscheidende Rolle.

Für den Einbau in ein neues root-Filesystem verwende ich selbst trotzdem weiterhin meine Version, da es sehr unwahrscheinlich ist, daß ich damit jemals auf einer 7490 ein SquashFS-Image der Versionen 1 oder 2 oder 3 entpacken werde (für V3 gibt es eigene Files) und dieser Platz im Image verschenkt ist.

Die schlechte Nachricht ist ohnehin, daß es offenbar einen (für mich zumindest) noch ungeklärten Unterschied zwischen 06.35 und den Vorgänger-Versionen gibt ... es ist mir weder mit meinen eigenen Patches noch mit den über den Freetz-Trunk erstellten Binaries gelungen, eine nicht komplett statisch gelinkte Version der squashfs-tools für Version 4 unter der Version 06.35 auszuführen (es gibt nicht einmal eine ordentliche Fehlermeldung und auch mit "strace" ist auf Anhieb nichts zu sehen). Die schon im Okt. Sept. 2014 erstellten Tools (dynamisch gelinkt) für SquashFS-Version 3 funktionieren hingegen auch unter 06.35 problemlos. Ob das für neu erstellte Binaries der squashfs-tools in Version 3.4 ebenfalls gelten würde, wollte ich im Moment lieber nicht testen und erst einmal die neue Version von modfs zu einem definierten Stand bringen. Daher sind die enthaltenen Tools für SquashFS3 mit dem zu diesem Zeitpunkt gültigen Stand (wenn das da überhaupt schon in Freetz aufgenommen war, ansonsten (per Dekret) mit der ersten in Freetz verfügbaren Version für die Target-Tools) erzeugt.

EDIT: Die Anpassung der Beschreibung in README und README.ger im Paket steht immer noch in der ToDo-Liste ... das hebe ich mir für die nahenden langen Winternächte auf. Also besser hier lesen und die Informationen in diesen Dateien als veraltet ansehen.

@splenditnet:
Jetzt irritierst Du mich etwas ... genau das macht das Skript ja. Das gerade laufende System kann natürlich nicht "on the fly" geändert werden.

Wenn die Frage eigentlich lauten sollte, ob das Dateisystem in der inaktiven Partition auch als Vorlage/Ausgangspunkt der Modifikationen dienen kann, lautet die Antwort: Nein. Dafür müßtest Du dann (wenn das originale AVM-Image nicht mehr zur Verfügung steht, denn das wäre natürlich der einfachste Weg) erst wieder ein tar-Archiv im richtigen Format daraus erstellen.

EDIT: Deine Ausgaben oben sehen aber so aus, als wäre die Box noch "neu", d.h. direkt mit 06.24 ausgeliefert. Dann erst mal ein Update auf irgendwas machen, notfalls auf die 06.25-Labor-Reihe bzw. auf die 06.29, wenn Du Dir beim Telnet-Daemon nicht zu helfen weißt. Dann kannst Du mit dem "bootmanager" wieder auf die 06.24 zurückschalten und dann auch modfs benutzen. Alternative ist das Setzen der notwendigen Einstellungen von Hand, in Deinem Falle fehlt ja nur die "linux_fs_start"-Angabe im Urlader. Wenn Du die auf "0" setzt, ist das dasselbe wie die fehlende Angabe, aber modfs ist zufrieden.

Den ganzen Aufstand mit einer fabrikneuen Box werde ich in modfs nicht auch noch veranstalten ... das sind mit zuviele Unbekannte, die da hineinspielen könnten. Wenn die Voraussetzungen nicht erfüllt sind (s. #1 weiter unten), streikt das Skript.

Als möglichen Test für Boxen, bei denen aus irgendwelchen bisher unerfindlichen Gründen ein Reboot mitten in der Verarbeitung erfolgt (das Skript enthält nur eine einzige Stelle mit einem "reboot"-Kommando und daher kann so ein Neustart eigentlich nicht innerhalb des Skripts ausgelöst werden, das müssen externe Ursachen (z.B. allg. Speichermangel) sein), könnte man noch das Beenden einiger AVM-Daemons vor der Abarbeitung von modfs in Erwägung ziehen.

Ein Aufruf von
sollte einen Großteil der AVM-Dienste herunterfahren und dabei aber das USB-Subsystem nicht anfassen (braucht man ja i.d.R. für die Abarbeitung von modfs).

Ich habe auch 10 Minuten nach der Ausführung dieses Aufrufs keinen automatischen Restart verzeichnet, damit ist da ein automatischer Start aufgrund eines Watchdogs für einen nunmehr fehlenden Dienst eher nicht anzunehmen.

Bei mir ergibt sich auf der 7490 nach diesem Kommando ein freier Speicherplatz von >115 MB im tmpfs, dabei läuft ein Syslog-Daemon, eine dropbear-Instanz, ein cron-Daemon und ein Skript zur Anzeige des VPN-Zustands per LED von mir selbst noch weiter ... zusätzlich zum dsld und avmike von AVM (womit die Internet-Verbindung immer noch steht, sogar davfs2 läuft noch); nur Telefonie, DECT, AHA, usw. sind raus aus dem Spiel und können nicht mehr dazwischenfunken.

EDIT: Was man in der Hitze des Gefechts auch leicht vergißt ... ich habe tatsächlich auf der HDD auch noch eine Swap-Partition, die vom FRITZ!OS automatisch eingebunden wird. Wenn die den "Speicherdruck" bei mir lindern sollte, kriege ich das ja nicht mal so richtig mit, solange ich nicht gezielt nach Paging-Errors schaue.