Timestamp for squashfs images

Bei früheren Problemen wurde mal festgestellt, daß sich AVM-Images in einem Feld im Superblock von denen unterscheiden, die mit den "offiziellen" Toolls erstellt wurden (neben der "big endian"-Version von AVM natürlich). Damals wurde das in den Freetz-Patches so geändert, daß in keinem Falle in diesem Feld der "offizielle" Wert (das Feld heißt "mkfs_time", auch in den Include-Files in den Kernel-Sources von AVM) verfügbar ist, sondern immer die Größe des Images: https://github.com/Freetz/freetz/blob/master/tools/make/squashfs4-host-be/patches/550-mkfs_time__AVM_BE_AVM_LE.patch

Diese Änderung erfolgte aber nur "auf Verdacht" - auf der Suche nach einer Erklärung für ein Problem.

Auf der anderen Seite ist genau dieser Zeitstempel praktisch die einzige sinnvolle Möglichkeit zu erkennen, wann das SquashFS-Image tatsächlich erstellt wurde, denn die enthaltenen Dateien haben i.d.R. ihren eigenen Zeitstempel und das Durchsuchen des gesamten Inhalts nach dem Eintrag mit dem größten Wert (als Anhaltspunkt für die letzte Änderung) ist nicht nur zeitaufwändig, sondern erfordert entweder die Möglichkeit, exakt dieses Image auch zu mounten (was bei AVM-Format außerhalb einer Box mit einem passenden Kernel schwierig wird) oder es zu entpacken bzw. seinen Inhalt aufzulisten (mittels -lls beim "unsquashfs" - was dazu auch erst mal vorliegen muß).

Ich habe diese Patches jedenfalls schon vor längerer Zeit in die von mir bereitgestellten, vorübersetzten Binärdateien eingebaut und es gab seitdem nie wirklich Beschwerden hinsichtlich irgendwelcher Inkompatibilitäten auf VR9- und GRX-Boxen.

Parallel habe ich aber auch noch eine zusätzliche Option (-no-mkfs-time) in das "mksquashfs" eingebaut, mit der dann wieder das von AVM verwendete Format reproduziert werden kann ... vorausgesetzt, man gibt die Option beim "mksquashfs" an. Zusätzlich sind noch die Patches enthalten, die das Nachrüsten dieser Option abwählbar machen, woraufhin sich das Ganze wieder "wie in Freetz" verhält.

Und da die Änderung von "mkfs_time" auf "image_size" damals auch im Rahmen eines "Verdachts" erfolgte, der unmittelbar mit dem Flashen bei einer "non-mirrored" Box im Zusammenhang stand, gibt es auch noch (als separaten Commit) das Hinzufügen dieser neuen Option zu allen "mksquashfs"-Aufrufen in "fwmod", bei denen am Ende ein Image für ein solches Modell herauskommen soll.

Ich hoffe/denke, ich habe damit alle Voraussetzungen erfüllt, um den Tools in Freetz und eben auch den durch Freetz erstellten Images die Verwendung des Zeitstempels anstelle der Größe "schmackhaft" zu machen ... das Ganze ist entstanden, weil ich im Boot-Manager (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager) irgendwie das Datum der letzten Modifikation des OS in einem Partition-Set (und das kann eben auch durch Freetz modifiziert worden sein) zu ermitteln hatte und das auch noch dann, wenn ich den Inhalt des Images nicht entpacken kann oder will und auch das Mounten nicht in Frage kommt.

Folgende Anmerkungen:

Warum ist neue Option optional für target und fix aktiviert für host?
Der Patch hat folgende sehr unschöne Eigenschaft: das Default-Verhalten des Tools ist unterschiedlich je nachdem, ob der Support für die neue Option miteinkompiliert wird (-DAVM_FORMAT_AS_OPTION) oder nicht. a) ist -DAVM_FORMAT_AS_OPTION gesetzt, so führt das zum Default use_standard_mkfs_time=TRUE, dadurch wird der Code sBlk->mkfs_time = (int) sBlk->bytes_used; NICHT ausgeführt. b) ist -DAVM_FORMAT_AS_OPTION dagegen nicht gesetzt, so entspricht das default- bzw. das einzige Verhalten dem Ausführen der Zeile sBlk->mkfs_time = (int) sBlk->bytes_used; Besser wäre es, wenn das Default-Verhalten immer gleich wäre (oder es den Preprocessor-Symbol AVM_FORMAT_AS_OPTION gar nicht gäbe) und das Abweichen vom einheitlichen Default-Verhalten übersteuert werden könnte.

@PeterPawn: Könntest du bitte deinen Patch überarbeiten? Ich würde -DAVM_FORMAT_AS_OPTION komplett eliminieren (sprich die von dir gewünschte Funktion soll immer unterstützt werden). Das Default-Verhalten soll dem bisherigen Verhalten entsprechen, die Option soll das Default-Verhalten übersteuern. Auch, was die Namengebung der Option angeht, wäre ich eher bei "no-size-in-mkfs-time" bzw. "no-avm-mkfs-time".

Btw. der Mehrwert der Option für Freetz ist mir nicht ersichtlich. Könntest du bitte die Notwendigkeit dieser Option für Freetz begründen? Abgesehen vom YourFritz-Bootmanager. Wie gehst du in dem Bootmananger mit dem Sachverhalt um, dass AVM das Feld mkfs-time mit size befüllt - da steht dir ja dann auch last modification time nicht zur Verfügung.

Und btw.:

Die Notwendigkeit, dass das Feld mkfs-time mit der Größe belegt ist, besteht darin, dass das Update von einer SquashFS-3 basierten Firmware auf die SquashFS-4 basierte Firmware sonst nicht funktioniert. mkfs_time befindet sich, soweit ich mich erinneren kann, im SuperBlock-4 genau an der Stelle, wo sich im SuperBlock-3 die Größe befindet. Wenn der nur SquashFS-3 unterstützende Kernel ein SquashFS-4 Image liest, reicht dieser AVM-Trick um dieses Image zu laden und zu starten.

Ohne, dass das Feld so belegt ist, wird Upgrade v3->v4 nicht funktionieren. Es ist natürlich eine andere Frage, ob man angesichts dessen, wie viele Jahre SquashFS-3 basierten Firmwares zurückliegen (6.3x waren es, wenn ich mich nicht täusche), an so was denken muss / möchte.

Edit: aus diesem Grund kann ich auch https://github.com/Freetz/freetz/pull/305/commits/d63572ab6a96b5884774166352979c7feec563fb nicht nachvollziehen. Denn meinem Verständnis nach wäre es (aus dem oben genannten Grund) eben für die Boxen mit FREETZ_AVM_HAS_SEPARATE_FILESYSTEM_IMAGE=y (man beachte y) notwendig.

Wie gehst du in dem Bootmananger mit dem Sachverhalt um, dass AVM das Feld mkfs-time mit size befüllt - da steht dir ja dann auch last modification time nicht zur Verfügung.

https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L956

Wenn es danach keine valide Info gibt, werden andere Infos gesucht oder es gibt auch mal keine Angabe. Der Zeitstempel im SquashFS-Superblock wäre nun mal die genaueste Angabe, alles andere ist eher geraten/extrapoliert und funktioniert auch bei manchen Boxen (z.B. das Dateidatum der "filesystem_core.squashfs" auf VR9-Boxen) und auf anderen nicht.

Ohne, dass das Feld so belegt ist, wird Upgrade v3->v4 nicht funktionieren.

Beim Upgrade von v3 auf v4 interessiert dieses Feld aber nicht ... dafür kommen (iirc) nur Boxen mit VR9-SoC in Frage und die arbeiten mit dem YAFFS2-Wrapper. Spätere Modelle (spez. GRX5) benutzen kein SquashFS3-Format mehr, da stellt sich die Frage eines solchen Übergangs also nicht.

Ob es für 40x0 noch FRITZ!OS-Versionen mit SquashFS3 gibt (in freier Wildbahn, die 4080 war ja lange ein Phantom), weiß ich aus dem Stand gar nicht - aber auch da würde wohl kaum die Größe eines SquashFS-Images anhand der Angabe bei Offset 8 im Superblock bestimmt, wenn es sich am Ende um ein v4-Image handelt.

Zumindest nicht bei der Installation und in den Kernel-Quellen für den SquashFS-Treiber (der dann beim Mounten ja verwendet wird), ist bei SquashFS4-Quellen auch nichts zu finden, was darauf hindeuten würde, daß es irgendeine anderweitige Nutzung des (nach wie vor in der "squashfs_fs.h" als "mkfs_time" firmierenden) Wertes gäbe.

Der 32-Bit-Wert an Offset 8 wäre (mit seinen max. 4 GB) ohnehin mittlerweile zu klein für die offiziell unterstützten Imagegrößen beim SquashFS (auch wenn das bei den "internen" Images nicht auffallen mag, weil die klein genug bleiben) - immerhin können aber durchaus auch SquashFS-Images von USB-Volumes gemountet werden, wenn der Kernel-Treiber das Format versteht; der Code in der "udev-mount-sd" gibt das her.

Naturgemäß ist das aber in der 6490 leichter zu realisieren (auf dem ATOM-Core zumindest und nur der zählt hier) oder auch auf den IPQ-Boxen, denn die nutzen halt das "offizielle" Format mit LE-Speicherung, während man bei den Modellen mit AVM-BE auch das passende Format haben muß, weil das Swappen der Werte im Kernel-Treiber leider nicht nur abhängig von der Signatur im Superblock erfolgt (das wäre mal eine weitere "Aufgabe", zumindest wenn man den Kernel ohnehin ersetzen will).

Frühere Modelle benutzen noch kein SquashFS4 - das hielt mit 6490 generell Einzug (m.W. erstmalig dort gesehen, aus der Zeit stammt auch mein erstes RE zum Lesen des Formats) und mit 06.5x (bzw. der Labor-Reihe dazu) dann auch Einzug bei den DSL-Boxen (aus der Zeit stammen dann die ersten Versuche, das Format auch selbst zu erzeugen).

Bei den Boxen mit Wrapper-FS erfolgt das Kopieren des inneren SquashFS-Images (filesystem_core.squashfs) immer als Datei - entweder aus der "/var/install" heraus, dann wird zuvor entweder das SquashFS-Image gemountet oder das "ext2"-Dateisystem mit dem Pseudo-Header (in dem das Feld an Offset 8 auch 0 wäre). Um es mounten zu können, muß der Kernel das Format kennen und verstehen - das gilt für SquashFS3 vor 06.36 (iirc die Labor-Reihe zur 06.5x) und seit irgendwann in der 07.19-Reihe auch wieder für SquashFS4.

Anschließend wird in beiden Fällen nur noch mittels cp -R der Inhalt dateiweise kopiert, hier kann das Feld "mkfs_time" im Superblock des Images keine Rolle spielen. Die Installation in der "/sbin/flash_update" aus dem "äußeren" Dateisystem (beim Start aus dem RAM) läuft ebenso ab, nur daß hier die Quelle nicht erst noch gemountet werden muß, weil sie unter /wrapper im laufenden System schon existiert - daher wird der Inhalt dort auch nur mittels cp -R einfach kopiert.

Ein Kernel mit Support für das SquashFS3-Format kann ein SquashFS4-Image nicht mounten und umgekehrt ... das dürfte auch exakt der Grund gewesen sein (kleinster gemeinsamer Nenner), warum AVM beim Wechsel von v3 auf v4 die Geschichte mit dem "ext2"-Image mit Pseudo-Header als BE-SquashFS-Image eingeführt hat. Ich wüßte jedenfalls keine Stelle bei Modellen mit "mirrored"-Aufbau, wo ein SquashFS-Image einfach so 1:1 irgendwohin kopiert wird, ohne daß es dabei als Datei behandelt würde und dann kommt die Dateigröße nun mal aus dem Inode.

Eine andere Frage ist es ggf. bei den Modellen mit nur einem einzelnen System. Wenn dort die Installation eines solchen SquashFS-Images als "letzter Schritt" vor dem Reboot durch das Laden eines entsprechenden LKM erfolgt (das "flash_update.ko" von AVM wäre ein Kandidat dafür), dann wäre es tatsächlich denkbar (wenn auch nicht sehr wahrscheinlich, denn das hätte i.d.R. auch Zugriff auf den passenden Inode), daß dieses LKM sich hinsichtlich der Größe am dritten Int32-Wert im Superblock orientiert (was dann aber das LKM unbrauchbar macht für die Installation anderer Formate, wo da nicht die Länge steht).

Andererseits steht bei diesen Modellen i.d.R. auch noch der Kernel VOR dem zu schreibenden SquashFS-Image in der Datei (das kann man sich heute noch z.B. bei der 4020 auch mit SquashFS4 ansehen) und ich würde sogar bezweifeln, daß dieses LKM Kenntnis davon hat, wo in der zu flashenden Datei das SquashFS-Image beginnt.

Und nur für den unwahrscheinlichen Fall, daß dieses "flash_update.ko" am Ende doch noch eine Prüfung des zu schreibenden Images vornimmt, dabei den Superblock lokalisiert und die darin zu findende Länge auf Plausibilität prüft (ggf. auch nur an dieser Stelle, weil der Code für dieses LKM mal mit v3 startete und für v4 nicht angepaßt wurde/werden sollte), habe ich den Patch für fwmod noch hinterhergeschoben und das dann eben auch für die Modelle, wo Kernel und Dateisystem NICHT getrennt sind.

Das war damals auch (wenn ich mich richtig erinnere) der Anlaß, warum ich überhaupt auf diesen zusätzlichen Unterschied beim AVM-Format kam - mit der passenden Hardware, auf der man das "flash_update.ko" daraufhin testen kann, hätte ich auch das noch einmal einer Überprüfung unterzogen. Um auf der sicheren Seite zu sein und das Flashen bei diesen Modellen nicht zu gefährden, solange ich das nicht ausschließen kann, gibt es die Änderung für fwmod.

Wenn der nur SquashFS-3 unterstützende Kernel ein SquashFS-4 Image liest, reicht dieser AVM-Trick um dieses Image zu laden und zu starten.

Das verstehe ich gar nicht ... was soll hier das "liest" heißen? Mounten und interpretieren kann der Kernel das ohnehin nicht und solange dieses "Lesen" mit Dateioperationen erfolgt (und es nicht um irgendwelche (unbekannten) Gültigkeitsprüfungen geht - die eben auch nur in proprietären AVM-Komponenten "versteckt" sein könnten, weil sonst nichts zu sehen ist), geschieht das halt auch in der Länge, die sich aus dem Inode für das Image-File ergibt. Ein Kopieren von Partition zu Partition (also "device->device" anstelle von "image->device") gibt es meines Wissens nicht - solltest Du das anders kennen, würde mich die Stelle interessieren.

Könntest du bitte die Notwendigkeit dieser Option für Freetz begründen?

Nein, selbstverständlich nicht - das geht bei genauem Lesen ja aus meinem Text im ersten Kommentar auch hervor, sonst müßte ich ja nicht etwas von "schmackhaft machen" schreiben.

Trotzdem gestatte ich mir die Gegenfrage ... worin liegt der Mehrwert für Freetz, daß die damit erzeugten Images KEINEN Zeitstempel haben und sich selbst die mit "normalem LE-Format" erzeugten Images (bei ARM- und Puma-(ATOM-)SoCs kommt ja das offizielle Format zum Einsatz) in ihrem Aufbau von denen unterscheiden, die mit den "offiziellen Tools" erstellt werden können?

Das Ganze dürfte am Ende ohnehin nur auf "Faulheit" bei AVM zurückzuführen sein und die Einführung eines Zeitstempels im Superblock bei den "offiziellen" Tools erfolgte ja auch nicht nur, weil man's auf einmal "schick" fand, sondern weil es einen Bedarf dafür gab.

Die nächste Version der SquashFS-Tools unterstützt dann für "reproducible builds" sogar das explizite Setzen dieses Zeitstempels auf einen angegebenen Wert: https://github.com/plougher/squashfs-tools/blob/master/README-4.4 - spätestens beim Update auf diese Version der Tools müßte man dann ohnehin wieder entscheiden, was man nun mit dieser neuen Option der "offiziellen Version" anstellt. Daher stammt auch die Namensgebung für diese Option "-no-mkfs-time" meinerseits ... der "-mkfs-time"-Patch für die nächste Version der SquashFS-Tools existierte bereits zu diesem Zeitpunkt und man könnte sogar mit dieser Version 4.4 der Tools (in zwei Durchläufen, wobei beim ersten die Länge ermittelt wird) das AVM-Format auch ohne weitere Patches und Optionen reproduzieren - nur ist es dann wohl sogar sinnvoller, das einfach per "dd" an Offset 8 in der Länge 4 zu schreiben, als zweimal zu packen.

Eine Argumentation mit "so wenig Änderungen ggü. den AVM-Quellen, wie möglich, damit spätere Updates weniger Aufwand mit sich bringen" dürfte auch aus offensichtlichen Gründen nicht verfangen - es gibt von AVM schließlich gar keine Quellen für Tools, mit denen man das "AVM-Format" (BE schon mal gar nicht, aber auch kein LE mit der Größe an Offset 8 im Superblock) reproduzieren könnte.

Daher auch die Argumentation/der Ansatz, das Verhalten der offiziellen Tools so weit wie möglich zu übernehmen und nur dort, wo es die Änderungen durch AVM tatsächlich erforderlich machen, das Verhalten durch zusätzliche Optionen abzuändern.

Daher kann ich auch die Aufforderung:

Das Default-Verhalten soll dem bisherigen Verhalten entsprechen

nicht so ganz verstehen ... wenn es (für Dich) ohnehin nur darum geht/eine Rolle spielt, wie sich die Programme im Freetz-Kontext verhalten und man da ohne weiteres (wo man es nicht absichtlich unterläßt, um eben den Zeitstempel später nutzen zu können) dann in Freetz die Optionen so verwenden kann, daß das bisherige Verhalten wieder abgebildet wird, warum muß dann unbedingt dieses "Default-Verhalten" der Tools sich von dem der offiziellen unterscheiden und zwar auch noch über das Maß hinaus, was einem AVM mit den Änderungen am Format aufzwingt?

Ich gehe mal davon aus, daß damit auch die Frage:

Warum ist neue Option optional für target und fix aktiviert für host?

beantwortet ist. Wenn die Option für die Host-Tools nicht fest aktiviert ist, müßte man ihre Verwendung in fwmod (die Gründe dafür stehen oben) von weiteren Symbolen abhängig machen, damit die Angabe der Option nicht zu einem Fehler führt.

Da kommt dann noch eine "Ungewißheit" hinzu, ob sich die ".config" seit dem Zeitpunkt der Erstellung der vorhandenen Tools nicht geändert hat (die derzeit bei der Prüfung von mir verwendeten Symbole MÜSSEN richtig gesetzt sein, damit fwmod auch in den Sonderfällen (-u, -p, etc.) richtig arbeiten kann), wenn der Benutzer das "fwmod" nicht im Rahmen von "make" aufruft (wo eine nachträgliche Änderung dann das Bauen neuer Tools auslösen ~~würde~~ sollte - sicher bin ich nicht, daß die Abhängigkeiten dort funktionieren würden), sondern direkt und mit den Optionen für die "Spezialeinsätze".

Die Tatsache, daß das -no-mkfs-time nach meinen Patches für das Erzeugen von Freetz-Images bei "mirrored"-Architektur eben nicht beim Aufruf angegeben wird, resultiert (a) aus der Erfahrung, daß die Größenangabe in diesem Feld dort offenbar nicht genutzt wird (der Superblock ist nach dem Mounten ohnehin nicht mehr von Interesse - das FS ist per Definition "read-only" und da ändert sich auch der Superblock nicht mehr) und (b) aus dem Wunsch/dem Bemühen, auch den Benutzern des Boot-Managers in einem Freetz-Image mit der Zeitangabe eine sinnvolle Information zukommen zu lassen im GUI.

Das alles gilt noch "innerhalb" von Freetz und hat mit der möglichen Nachnutzung der Tools für andere (ebenfalls FRITZ!OS-bezogene) Zwecke noch gar nichts zu tun. Aus diesen Gründen (weil man hier auch die ggf. notwendige Angabe zusätzlicher Optionen "im Griff" haben sollte bei der Nutzung innerhalb von Freetz) wird die Option für die Host-Tools IMMER aktiviert und ich halte es nicht für zielführend, das jetzt wieder umzudrehen. Ggf. kann man für die Target-Tools überlegen, ob man das da ebenfalls automatisch aktiviert oder nicht ... damit das dann eine Auswirkung hat, muß der Benutzer die Tools überhaupt erst mal einbauen lassen, was bei einem Freetz-Image vermutlich auch eher selten der Fall oder auch nur sinnvoll ist.

Ich habe aber auch kein Problem damit, das STÄNDIG zu aktivieren und die Option (allerdings im beschriebenen Kontext, daß anzugebende Optionen immer eine Änderung des Verhalten vom Standard (und den setzen die offiziellen Tools und auch nicht AVM) zur Abweichung bewirken und nicht umgekehrt) permanent zu integrieren.

Da es wohl auch irgendwann eine gute Idee wird, die SquashFS-Tools in Freetz auf die neue Version umzustellen (es gab auch Bugfixes in der 4.4), könnte man meinetwegen auch noch den Namen der Option ändern ... aber nicht in irgendetwas Kompliziertes oder Ausschweifendes, sondern dann schlicht in "-avm-strict" oder ähnlich, weil es ziemlich egal ist (zumindest bei der Benutzung des Programms), was da nun im Detail passiert bei der Benutzung der Option.

Fazit: Bei der Definition, was "Standard-Verhalten" ist, sind wir unterschiedlicher Ansicht. Die ganze Aktion macht allerdings auch keinen Sinn mehr, wenn die mittels Freetz erzeugten Images dann bei den "mirrored"-Modellen weiterhin keine Zeitstempel tragen (das war ja das Ziel, weil meine "pre-built tools" ohnehin schon seit ca. einem Jahr den Zeitstempel erzeugen) - sollte also das mit dem

FREETZ_AVM_HAS_SEPARATE_FILESYSTEM_IMAGE=y (man beachte y)

ernst gemeint sein für die Anwendung von "-no-mkfs-time", lassen wir das besser komplett, denn dann lohnt es (für mich) den Aufwand nicht.

Bei der Benennung der Option und beim Wegfall der optionalen Einbindung (und damit von "AVM_FORMAT_AS_OPTION") kämen wir sicherlich zu einer Übereinkunft, diese macht aber nur dann auch Sinn, wenn die strittigen Punkte zuvor geklärt sind - Änderungen für den Mülleimer werde/will ich nicht ausführen.

Das abweichende Ergebnis im Standardverhalten, wenn AVM_FORMAT_AS_OPTION gesetzt ist oder nicht, ist durchaus Absicht und am Ende nur dem Bestreben geschuldet (basierend auf früheren Erfahrungen), auch mit dem Patch den "Status Quo" der Tools in Freetz (optional) erhalten zu können - braucht's den tatsächlich nicht, kann das logischerweise entfallen.

Das, was ich in Bezug auf Upgrade v3->v4 geschrieben habe, sind meine Erinnerungen aus dem Kopf. Diese aus dem Stand zu belegen, ohne die zeitaufwendige Suche dafür betreiben zu müssen, kann ich nicht. Es sind nur dunkle Erinnerungen, dass ich dies in dem Quellcode irgendeiner Kernel-Komponente gelesen habe (ob das SquahFS oder flash_update war oder sonst was, kann ich nicht mehr sagen).

Wenn du dir allerdings sicher bist, dass ich mich diesbezüglich täusche und derartiges Belegen des Feldes zur Laufzeit nicht benötigt wird, dann kann ich mit dem neuen Default-Wert leben. Allerdings hätte ich dann trotzdem die Bitte, das Symbol AVM_FORMAT_AS_OPTION komplett zu eliminieren, die Option no-mkfs-time bzw. strict-avm (der Vorschlag gefällt mir) soll es einfach immer geben. Das würde dann das Problem des unterschiedlichen Default-Verhaltes sozusagen mitlösen.

Die meisten bzw. sogar alle Änderungen an den *.mk, Config.in Dateien wären dann auch nicht mehr notwendig und könnten komplett reverted werden. Es wären nur noch der Patch an sich und die Änderung an fwmod notwendig.

In Bezug auf den Patch noch folgendes:

ich habe nichts dagegen, wenn du deine Änderungen direkt in den 550-mkfs_time__AVM_BE_AVM_LE.patch integrierst. Die Änderungen gehören inhaltlich zusammen.
die beiden Stellen - das Parsen der Option und die Hilfe - gehören mit #if (TARGET_FORMAT == AVM_BE || TARGET_FORMAT == AVM_LE) umrandet.

Danke!

p.s. Und, wenn ich noch einen Wunsch äußern dürfte, so könntest du bitte auf die nicht zwingend notwendigen Whitespace-Änderungen verzichten. Ja, die beiden Zeilen, die mit else if(strcmp(argv[i], beginnen, sind komisch aligned und das eine Leerzeichen ist überflüssig, aber es gehört nicht zum Inhalt deiner Änderungen.

gehören mit #if (TARGET_FORMAT == AVM_BE || TARGET_FORMAT == AVM_LE) umrandet.

Das versteht sich - bei der Änderung der Struktur - schon von selbst ... bisher ist das - implizit - auch schon so, weil das zusätzliche Symbol "AVM_FORMAT_AS_OPTION" nur zusammen mit dem AVM-Format in den Symboldefinitionen auftaucht; selbst wenn da keine "echte" Abhängigkeit durch irgendwelche #if zu sehen ist im Quelltext.

so könntest du bitte auf die nicht zwingend notwendigen Whitespace-Änderungen verzichten [...] aber es gehört nicht zum Inhalt deiner Änderungen.

Das ist das Ergebnis eines einzigen Commits, nachdem ich die Quellen entsprechend geändert hatte (so etwas mache ich nicht "von Hand") und da ich dabei auch die Einrückung korrigiert hatte (daß sie nicht stimmt, schreibst Du ja selbst), ist das eben auch Bestandteil ebendieses "diff" (das macht nebenbei bemerkt auch mein Editor selbst, wenn ich Quelltexte reformatieren lasse). Ich werde auch nicht hingehen und daraus jetzt zwei Commits machen ... das ist ein Vorgang, der im Git in dieser Form nicht vorgesehen ist.

Und ja, ich habe das "Danke!" auch gelesen und wahrgenommen - und es als "Friedensangebot" verstanden, womit ich hoffentlich nicht vollkommen verkehrt liege.

Denn ich kann es mir tatsächlich nicht verkneifen zu grinsen, wenn solche Anmerkungen zu inhaltlichen Änderungen von Deiner Seite kommen (und ich streue da vielleicht auch Salz in (m)eine Wunde, aber das liegt eben auch daran, wie weit ich das mittlerweile "verarbeitet" habe und das ist offenbar nicht so gut gelaufen) ... gilt das jetzt generell, daß man solche (leeren) Änderungen an fremdem Code nicht ausführt oder geht es nur darum, daß das in Deinen Augen dann auch ein gesonderter Commit sein sollte?

https://github.com/er13/YourFritz/commit/9defda1dc4e81fe58e00f3cd1e51ca2d5be4b20d#diff-9021780788c65e188836ebf401673f92

Aber egal - das Grinsen verfliegt ja irgendwann auch wieder ... ich schaue mal, was ich tun kann. Ich reaktiviere jedenfalls meinen Branch wieder - ob es hier erst mal ein Zurücksetzen auf c2d31e7321ec04b81e27eee5bc9b198e25fab07c mit anschließendem "push -f" gibt oder nicht (ein "revert" gibt es im Git (richtigerweise) nicht), ist am Ende nicht meine Entscheidung.

Ich kann aber schon jetzt deutlich ansagen, daß das Überarbeiten weder heute noch morgen stattfinden wird - der Branch, auf dem der PR basierte, existierte bereits seit August 2019 und auch wenn ich den jetzt gerade mal (zusammen mit dem "bc"´-Patch, auf den ich im IPPF aktuell wieder gestoßen wurde) versucht habe als PR unterzubringen (weil es eine geänderte Version des Boot-Managers geben wird und diese Änderungen hier thematisch wieder dazu paßten und ohnehin noch "herumlagen"), ist das kein Thema, mit dem ich mich im Moment befassen kann oder will.

Das heißt dann ... entweder es funktioniert jetzt erst einmal mit den vorgeschlagenen Änderungen (die damit auch gleichzeitig die Chance erhalten, von den Freetz-Benutzern in der Praxis getestet zu werden) und ich packe mir die Änderungswünsche auf "hold" und erledige das bei passender Gelegenheit mit oder es wird eben zurückgedreht, dann mache ich nur meinen alten Branch wieder auf (die Daten existieren ja ohnehin im Stream und es fehlt nur das Tag).

Ich will ohnehin die 4.4er-Tools einbauen und auch das "append" als Feature generell noch einmal überdenken (derzeit wird es iirc ja immer noch komplett entfernt, weil es in Freetz nicht wirklich etwas bringt), weil das auf der Box für Änderungen, die nur zum "Einstieg" in eine Box dienen sollen, natürlich jede Menge Zeit sparen kann, wenn man nicht alles neu packt, sondern nur die Verwaltungsstrukturen überarbeiten (und hinten fortschreiben) läßt - das klappt i.d.R. sogar ganz gut (nur den allerersten Block muß man zusätzlich löschen und neu schreiben lassen im Flash), weil hinter den Images der Flash-Speicher ohnehin gelöscht ist (oder bei UBI gleich die LEBs per Wear-Leveling verteilt werden, was das (häufigere) Schreiben des ersten SquashFS-Blocks dann sogar wieder zur läßlichen Sünde macht).

Mit den "originalen" SquashFS.-Tools kann man das (auf LE-Boxen) auch ganz gut testen - das lohnt sich (für meine Zwecke) also auch ganz bestimmt, das ebenfalls zu überarbeiten und ggf. auch an die AVM-Patches anzupassen.

Ich muß auch zu meiner Schande gestehen, daß ich tatsächlich für die eigenen Zwecke immer noch die allererste Implementierung von mir in Benutzung habe beim "unsquashfs" (die konnte/kann sowohl das BE- als auch das LE-Format entpacken, weil sie das erst zur Laufzeit entscheidet, welche Werte nun getauscht werden müssen und welche nicht) und ich erst jetzt mitbekommen habe, daß die Aufteilung in "-avm-be" und "-avm-le" in Freetz nicht nur eine Marotte ist und mit dem "bevorzugten" Format zusammenhängt - nein, das Tool ist tatsächlich "dümmer" geworden und liefert auch nur noch sehr "uneinheitliche Ergebnisse", wenn man damit versuchen will, die Natur eines SquashFS-Images zu "entschlüsseln".

Hier mal ein Beispiel, wie das aussieht - alles mit einem ganz normalen Freetz-Stand ohne weitere Patches auf einem RasPi, wobei die Tools hier für GRX5 (7590) gebaut wurden und einfach zur Demo genommen werden, weil sie nun mal "da" sind. Als Image werden die beiden "filesystem.image" aus einer 6490-Firmware verwendet, weil man da gleich beide Versionen der "byte order" vorliegen hat und sich das so schön vergleichen läßt:

pi@pi4:/media/pi/extern_10_320/pi4 $ mkdir work/6490
pi@pi4:/media/pi/extern_10_320/pi4 $ tar -x -v -f builds/dl/fw/FRITZ.Box_6490_Cable-07.12.image -C work/6490/ ./var/remote/var/tmp/filesystem.image ./var/remote/var/tmp/x86/filesystem.image
./var/remote/var/tmp/filesystem.image
./var/remote/var/tmp/x86/filesystem.image

# Passendes Tool für das BE-Image und das "-stat" ist kein Problem, auch nicht, wenn man noch "-scan" machen läßt:
pi@pi4:/media/pi/extern_10_320/pi4 $ builds/grx5/tools/unsquashfs4-avm-be -s -k work/6490/var/remote/var/tmp/filesystem.image
Found a valid superblock at offset 0x00000000 while scanning work/6490/var/remote/var/tmp/filesystem.image.
Found TI checksum (0xFF7DE221) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on work/6490/var/remote/var/tmp/filesystem.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 5657.79 Kbytes (5.53 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 113
Number of inodes 1065
Number of ids 1

# Aber wehe, es geht um das LE-Image (hier das für den ATOM-Core):
pi@pi4:/media/pi/extern_10_320/pi4 $ builds/grx5/tools/unsquashfs4-avm-be -s work/6490/var/remote/var/tmp/x86/filesystem.image
Found TI checksum (0xA73A4F73) at the end of the image.
Filesystem on work/6490/var/remote/var/tmp/x86/filesystem.image is (4:0), which is a later filesystem version than I support!
# Das mit dem "later version" ist ja schon mal Unfug, "different byte order" wäre ggf. noch eine sinnvolle Angabe.

# Noch lustiger wird es, wenn man jetzt auch hier noch das "-scan" hinzufügt:
pi@pi4:/media/pi/extern_10_320/pi4 $ builds/grx5/tools/unsquashfs4-avm-be -s -k work/6490/var/remote/var/tmp/x86/filesystem.image
Unable to find something looking like a SquashFS superblock in work/6490/var/remote/var/tmp/x86/filesystem.image.
# Da ist der LE-Superblock, der eben noch die falsche Version hatte, jetzt komplett unauffindbar.

# Er ist aber gar nicht wirklich weg ... denn mit dem passenden Tool ist der dann wieder zu finden, sogar mit "-scan" als Option:
pi@pi4:/media/pi/extern_10_320/pi4 $ builds/grx5/tools/unsquashfs4-avm-le -s -k work/6490/var/remote/var/tmp/x86/filesystem.image
Found a valid superblock at offset 0x00000000 while scanning work/6490/var/remote/var/tmp/x86/filesystem.image.
Found TI checksum (0xA73A4F73) at the end of the image.
Found a valid little endian SQUASHFS 4:0 superblock on work/6490/var/remote/var/tmp/x86/filesystem.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 23631.40 Kbytes (23.08 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 343
Number of inodes 3752
Number of ids 1
# Auch das ist noch plausibel ...

# Wild wird es dann aber, wenn man mit dem LE-Tool (auf einer LE-Plattform wie dem RPi) auf das BE-Image losgeht:
pi@pi4:/media/pi/extern_10_320/pi4 $ builds/grx5/tools/unsquashfs4-avm-le -s work/6490/var/remote/var/tmp/filesystem.image
Found TI checksum (0xFF7DE221) at the end of the image.
Reading a different endian SQUASHFS filesystem on work/6490/var/remote/var/tmp/filesystem.image
Filesystem on work/6490/var/remote/var/tmp/filesystem.image is (4:0), which is a later filesystem version than I support!
# Das ist jetzt auf einmal nicht mehr nur eine "later ... version than I support", sondern ein "different endian ... filesystem".

Das Ergebnis in Freetz ist jedenfalls in der derzeitigen Implementierung (ich wage sogar zu sagen: mittlerweile) meilenweit von einem "universellen" Gebrauch entfernt ... nicht nur, daß es keine Images mit der anderen Byte-Order mehr entpacken kann (packen muß gar nicht sein), es erkennt nicht mal mehr zuverlässig das korrekte Format und ist bei der Untersuchung, wie man so ein Image nun handhaben sollte, alles andere als hilfreich.

Das geht schon damit los, daß "different endian" (was es bei SquashFS4 im Original logischerweise gar nicht mehr gibt, weil das alles nur noch LE ist - also muß/müßte die Ansage aus einem Patch in Freetz kommen) nicht ein Stück weiterhilft bei der Auswahl des passenden Dateinamens für den "Entpacker", solange man nicht zusätzlich noch ermittelt, was denn "not different" als Byte-Order wohl wäre.

Die klare Ansage, welche Byte-Order das vorliegende Image nun verwendet, gibt es nur mit dem "passenden" Tool und dann ist sie eigentlich auch einigermaßen überflüssig, weil man das dann irgendwie schon wußte (sonst hätte man das Tool ja nicht auswählen können).

Das war definitiv schon mal anders ... vielleicht sogar "besser" (das ist halt Ansichtssache) - zumindest in meinen eigenen Patches, die irgendwann von Dir mal in Freetz - i.d.R. aber nur in abgewandelter/eigener Form - übernommen wurden und wo ich dann (eben weil ich ohnehin meine eigenen Binaries basierend auf meinen Patches hatte) nicht so genau hingesehen habe, welche Funktionen da nun wie übernommen wurden und was dabei auch auf der Strecke blieb.

Ich Honk habe dann irgendwann einfach auf die eigene Implementierung verzichtet und sie entsorgt und (zumindest für meine Nutzer, denen ich vorübersetzte Programme zur Verfügung stelle) nur noch die Freetz-Versionen verbreitet, ohne mir etwas dabei zu denken.

Bis ich dann irgendwann beim "Vormachen" von Abläufen, die eigentlich ganz einfach sein sollten nach meiner Ansicht und Erfahrung (auf meinen Systemen halt), so richtig schön auf der Nase gelandet bin und seitdem trage ich mich auch wieder mit dem Gedanken, für mich und meine Projekte die originalen Tools (erneut) an die AVM-Änderungen anzupassen und das dann aber wieder so, daß tatsächlich mit einem einzigen Binary auch alle Formate entpackt werden können.

Meine ganzen Änderungen hinsichtlich TI-Prüfsumme, Suche nach dem Superblock in den "combined images" und das Überlesen eines ggf. vorhandenen NMI-Vectors (der vermutlich bei der 4020 auch die Leute vom FKIE hat auflaufen lassen bei ihrer Analyse der 4020-Firmware mit den Freetz-Tools) hatten am Ende ja nur einen Sinn - nämlich einen "universellen Entpacker", der jedes AVM-Image zerlegen kann.

Daher kann/will ich auch nicht versprechen, daß ich tatsächlich noch die gewünschten Änderungen an der (älteren) Version 4.3 der SquashFS-Tools ausführen werde - das könnte wieder stark dafür sprechen, das am Ende auch hier doch wieder auf den Stand vor dem PR zurückzusetzen, wenn meine derzeitige Implementierung der Patches mit all ihren Mängeln nicht gut genug ist.

Aus ebendiesen Gründen haben ich diesmal aber auch überhaupt keine Bauchschmerzen, wenn das jemand selbst so ändert, wie er/sie es für richtig hält - das "Ziel" für mich war und ist der Zeitstempel in den Freetz-Images und wenn es den gibt, ist das ein Vorteil auch für die Freetz-User, die meinen Boot-Manager einbauen lassen und nutzen wollen.

Zwei Freetz-Images, basierend auf demselben FRITZ!OS-Stand, kann man nämlich (zumindest in der "Neustart"-Seite) auch nur dann auseinanderhalten, wenn es noch eine Info zum Datum der Modifikation dieser Version gibt ... die anderen Angaben (in erster Linie die AVM-Version und deren Datum) sollten für diese beiden Systeme identisch sein, was eine Entscheidung für oder gegen das Umschalten erschwert, wenn man ein bestimmtes System haben möchte.

Spätestens auf GRX-Boxen (oder anderen mit UBI-Layer vor dem SquashFS-Image) kann man sonst nur noch anhand des Dateidatums einer hoffentlich vorhandenen "Marker-Datei" (bei Freetz wäre das die "/etc/.freetz-version") erkennen, wann/ob die Firmware modifiziert wurde ... beim Gebrauch von "fwmod -u" und "fwmod -p" fehlt aber i.d.R. auch diese Datei im Image (weil sie nur bei DO_MOD=1 erstellt wird), solange der Benutzer sie nicht selbst hinzufügt.

Es gibt also durchaus auch mit Freetz erstellte Images, bei denen es außer der "mkfs_time" keine Info gibt, wann sie erstellt wurden - und wenn der Boot-Manager die Angabe von der "/etc/.freetz-version" bevorzugt, geschieht das auch nur in der Annahme, daß dieses Image tatsächlich danach nicht erneut modifiziert wurde.

Wenn "mkfs_time" deutlich öfter präsent ist, wäre es sogar wieder plausibler, auf diese Angabe als primäre Quelle umzuschwenken, denn es kann zwar zusätzliche Änderungen geben, die an der "/etc/.freetz-version" nichts ändern, aber an anderen Dateien - der umgekehrte Fall (Ändern einer Datei im Inhalt des SquashFS-Images, ohne den Zeitstempel im Superblock zu ändern) ist undenkbar. Zumindest solange diese Änderung nicht absichtlich "verschleiert" wird, z.B. eben mit der neuen Option "-mkfs-time", mit der dann eine wählbare Zeit des Erstellens gesetzt wurde (ab 4.4-Tools).

Daß ich anstelle des einfachen "Wunsches" nach einem Zeitstempel auch für Freetz-Benutzer dann gleich die dazu notwendigen Patches bereitgestellt habe, muß dabei auch nichts bedeuten ... es hat die Sache halt beschleunigt (oder hätte es können, wenn es wieder zurückgedreht werden sollte). Andererseits lag das jetzt so lange bei mir rum, daß es auch schon anfing zu riechen.

Freetz / freetz

Timestamp for squashfs images #305