Die automatische Suche bei AVM nach derselben Version, wie die bereits auf der Box installierte, verläßt sich darauf, daß "juis_check" mit Parameter "-c" (dadurch wird "Patch" dekrementiert, aus 07.12 wird also 07.11) bei der Abfrage von AVM auch die richtige Antwort erhält.
Mangels aktiver Version 07.12 kann ich das für eine 7490 gerade nicht überprüfen ... aber man kann jederzeit selbst diesen Aufruf machen (die notwendigen Dateien stehen im "modfs"-Archiv im "bin"-Folder) und nach der Anzeige (fast am Ende) in der "modfs_Download.txt" liefert AVM eben die Antwort, daß es keine neuere Version gäbe (der Return-Code ist 2) ... da kann "modfs" dann auch keine Version von AVM laden. Einen anderen Weg als das Dekrementieren von "Patch" kenne ich nicht, um die aktuelle Version bzw. die URL für deren Download zu ermitteln ... bisher hat das eigentlich auch immer für die aktuelle Version geklappt.
Aber wenn das mal nicht funktioniert, kann man ja einfach selbst die notwendige Version laden (woher auch immer) und auf der Box ablegen ... beim Aufruf mit "modfs update
image-name" kann man den Namen der Image-Datei ja dann angeben.
Worin der Fehler beim "mksquashfs" in der anderen Log-Datei jetzt bestehen soll, kann ich auch nicht sicher erkennen ... mich irritiert aber schon die Länge des Protokolls, denn selbst wenn das ein Ringbuffer ist und die ersten Zeilen auch mal überschrieben werden können, so würde doch ohne zusätzliche Angaben (von denen da oben ja nichts steht) ein Ringbuffer für 64 KB angelegt:
https://github.com/PeterPawn/modfs/blob/master/modfs#L2816 und da sollte deutlich mehr hineinpassen (der Platz ist auch reserviert und würde bei Speichermangel nicht fehlen), als man in der Datei sehen kann.
Außerdem verstehe ich halt nicht, warum das Skript hier (zumindest sieht man das in der Datei "modfs_Fehler.txt") das "tmpfs" der Box als "Arbeitsverzeichnis" auserkoren hat - da fehlt aber auch der komplette Beginn der Datei (oder zumindest des Protokolls im Ringbuffer), in dem man das irgendwie recherchieren könnte (da steht dann auch die "Aufrufzeile", die man zum Verfolgen braucht).
Wie das aussehen würde, kann man sich in der anderen Datei ansehen. Da ich (siehe weiter vorne, war aber gerade auch erst irgendwo Thema) auf die korrekten Größenangaben und passenden Abläufe bei den "nicht update"-Aufrufen aber auch nicht mehr schwören würde, würde ich es hier einfach noch einmal mit dem erwähnten "update"-Aufruf mit Angabe der Datei versuchen ... natürlich auf einer frisch gestarteten Box.
Dann sollte auch die Protokoll-Datei ausreichend groß angelegt werden und man sieht ggf. mal ein komplettes Protokoll. Es ist nämlich (in der "modfs_Download.txt") durchaus noch richtig, wenn der Download in das "tmpfs" erfolgt ... aber spätestens an dieser Stelle:
https://github.com/PeterPawn/modfs/blob/master/modfs#L3316 , wo dann 134 MB (zusätzlich) an freiem Speicherplatz zum Entpacken des Images gesucht werden, sollte auf einer 7490 (und auch Deine hat - nach der Anzeige in der "modfs_Download.txt" am Beginn - nur 118 MB im "tmpfs" gesamt) eine zwangsweise Umschaltung auf ein Arbeitsverzeichnis auf der "ext3"-Partition (oder im NAND, da aber nur bei passenden Environment-Settings) erfolgen.
Denkbar, daß das beim Aufruf ohne weitere Parameter (also beim "Klonen" des derzeit installierten Systems) nicht mit den passenden Größenangaben läuft ... aber seitdem ich auch den Test, ob die Versionen in beiden Partitionen tatsächlich identisch sind, am Beginn deaktiviert habe (schon vor längerer Zeit), würde ich auch nichts mehr auf die korrekte Funktion dieses Zweigs geben - erst recht nicht angesichts des gestiegenen Platzbedarfs der AVM-Firmware.
Eigentlich soll(te) bei dieser Version (wenn wirklich die Partitionen dasselbe System enthalten) nur das laufenden Root-FS (also die "filesystem_core.squashfs" aus dem "wrapper"-Verzeichnis) entpackt, modifiziert, eingepackt und in die (zweite) YAFFS2-Partition kopiert werden - dafür braucht man weniger Platz, weil weder die originale Image-Datei, noch "kernel.image" oder "filesystem.image" irgendwo zwischengelagert werden müssen. Was da jetzt konkret bei der Suche nach genug freiem Speicher als Größenangabe verwendet wurde, weiß ich nicht ... steht auch nicht in der "modfs_Error.txt" (warum auch immer das da fehlen mag, denn 64KB reichen bei mir sogar für 694 Zeilen:
Code:
/var/media/ftp/YourFritz/modfs # wc -l modfs.log.1575573159
694 modfs.log.1575573159
/var/media/ftp/YourFritz/modfs # ls -l modfs.log.1575573159
-rw-r--r-- 1 root root 63028 Dec 5 20:12 modfs.log.1575573159
/var/media/ftp/YourFritz/modfs #
) und daher kann ich dazu auch nichts sagen (jedenfalls nicht im Moment). Wenn das generell zu lang werden sollte als Protokoll (bisher waren 64 KB die max. Größe für die Ringbuffer-Programme von AVM, die da ja nachgenutzt werden), kann/muß man einfach ein paar der "modscripts" auslassen (EDIT: also die Datei selbst oder nur die "x"-Flags löschen), wenn man erst mal die generelle Funktion abklären will - das ergibt dann auch weniger Einträge in der Protokoll-Datei (die ja bei Dir > 100 KB sein soll mit ihren 552 Zeilen, wobei die Zeitstempel schon mal als 4 Byte "epoch" gespeichert sind und nicht als 26 Byte Zeichenketten).
Aber wenn man ganz sichergehen will, zwingt man einfach "modfs" per Environment-Variable auf ein bestimmtes Arbeitsverzeichnis ... das wäre hier ein Aufruf mit:
Code:
MODFS_WORKING_DIR=/var/media/ftp/SMI-USBDISK-02 modfs ...
und dann sollte - bei genug freiem Platz auf der Partition - das Ganze auch durchlaufen; jedenfalls wenn es nicht noch der richtigen Antwort vom JUIS von AVM bedarf (was man mit dem "update
imagefile" vermeidet).
=========================================================================
Denn selbst wenn ich (mit meinem Tool "juis_check") heute von Hand nach einer Nachfolgeversion für 07.11 suche (und zwar auch mit der richtigen "Revision", während "-c" die auf "00000" setzen würde), erhalte ich auch die Auskunft, es gäbe keine neuere Firmware:
Code:
vidar:/home/FritzBox/FB7490/firmware $ juis_check fb7490 Version=113.07.11-68718
usr/local/bin/juis_check: No newer version found, check was made with source version '113.07.11-68718'.
Ich glaube erst mal nicht, daß mein Skript plötzlich "kaputt" sein soll ... eher käme mir da eine Änderung bei AVM in den Sinn, die sich auf das Ergebnis auswirkt.
Dazu müßte man aber auch wieder wissen, wie das für die anderen Programme zur JUIS-Abfrage aussieht (das mit der Suche nach der aktuellen Version ist ja schon eine Besonderheit von "juis_check" (die anderen brauchen das ja auch nicht, während es genau für "modfs" erforderlich war) und das Verstecken der realen MAC-Adresse ebenfalls) und dafür habe ich im Moment weder Zeit noch Lust.
Erst dann, wenn ich definitiv weiß, daß es an meinem eigenen "juis_check" liegt und dieses von AVM irgendwie erkannt und mit abweichenden Antworten "versorgt" wird, sehe ich hier die Notwendigkeit, mir das genauer anzusehen.
EDIT: Ja, für die 07.1x-Versionen passen die Angaben zum benötigten Speicherplatz einfach nicht mehr ... die haben schon im entpackten Zustand mehr als 90 MB und in die Größenangabe für den benötigten Platz (96 MB in "free_space_for_unpack_tmpfs":
https://github.com/PeterPawn/modfs/blob/master/modfs#L88) sollte da (nach den früheren Berechnungen) noch das Image selbst auch reinpassen - das geht natürlich absehbar schief und bei der Variante mit dem Download wird für das Image ein anderes Verzeichnis gewählt (was das Problem entschärft, weil damit per se nicht genug Platz bleibt und auf eine Partition ausgewichen wird) bzw. beim Update mit vorhandener Datei liegt das dann auch an einem anderen Ort und braucht zusätzlichen Platz beim Entpacken des Firmware-Images (das ist noch nicht das Entpacken des SquashFS-Images), was ebenfalls hilfreich ist beim "Verdrängen" aus dem (begrenzten) "tmpfs".
Jetzt könnte man hingehen und die Angaben (deutlich) erhöhen ... mit dem Ergebnis, daß es für frühere Versionen dann wieder zuviel wäre. Ein dynamisches Ermitteln des tatsächlich benötigten Platzes liegt jenseits dessen, was ich hier noch implementieren will.
