ein klassischer Fall von "tot gepatcht"
War ja meine Vermutung in der E-Mail ... dann kam wieder etwas dazwischen und ich habe das Problem weitgehend aus den Augen verloren, da es bei mir erst mal mit abweichendem PATH und statischer Busybox vor der von AVM in der Suchreihenfolge als Provisorium lief.
Ich habe irgendwo weiter
vorne mal noch ein Problem mit dem ImageMagick-Paket "notiert" (ist unabhängig von Modell und Version der Box) ... ich weiß auch, daß das eigentlich in ein Ticket gehören würde - also "ad libitum", ob das als "Meldung" wahrgenommen wird oder nicht.
Aber Hut ab vor dem Aufwand, die Patches so weit glattzuziehen, wie Du das bis jetzt gemacht hast.
Wenn ich mit dem TFFS wieder durchblicke (nach meinem Eindruck jedenfalls), schaue ich als nächstes nach, wie AVM das mit dem SquashFS4 wirklich gelöst hat - da ist ja auch noch etwas zu klären, irgendwelche ungeklärten Kompressionen für irgendwelche Tables am Ende des Images spuken da noch in meinem Hinterkopf herum.
Bei den ganzen Patches für das GUI würde ich als Idee eher in den Ring werfen, auf echte "remove patches" künftig zu verzichten und die Punkte für deaktivierte Funktionen der Stock-Firmware eher über CONFIG-Variablen oder sogar über eigene FREETZ-Variablen und deren zusätzliche Abfrage im Lua-Code auszublenden, als da weiterhin einfach komplette Blöcke aus den Files zu stanzen. Das ist wesentlich fehlerträchtiger als das Ausblenden über Schalter und bei den wenigen noch mit dem neuen GUI beglückten NOR-Modellen mag der gesparte Platz ja etwas bringen, bei den NAND-Modellen ist im Moment so viel "verschwendeter Platz" vorhanden, daß man eigentlich alles, was sich nicht direkt mit Freetz-eigenen Paketen beißt, besser drin lassen und nur irgendwie den Start oder die Anzeige verhindern sollte. Eine einheitliche Behandlung des alten und des neuen GUI halte ich ohnehin für utopisch, auch wenn in den "handelnden" Lua-Files gar nicht soo sehr viel geändert wurde, wie man beim geänderten Design vermuten könnte ... das ist schon sehr schön in Inhalt und Design geteilt.
Wenn man aber "einen Schnitt" bei der Bearbeitung von solchen "remove patches" machen will, dann bietet sich dieses AVM-Update förmlich dazu an ... wenn man die bisher veröffentlichten Beta-Versionen zugrunde legt, bleiben am Ende noch die 7360 und die 7390 als NOR-Modelle (mit potentiellen Platzproblemen) übrig, die man bei der 7390 locker durch "external" im NAND-Flash lösen kann und wie verbreitet die 7360 ist, weiß ich nicht. Aber dann muß man da eben auch auf USB und "external" setzen.
Wie es bei den Repeatern (den moderneren) überhaupt im Innern aussieht, weiß ich allerdings nicht ... finde auch auf Anhieb keine passenden Support-Daten, wo man mal nachsehen könnte, wie da das Betriebssystem läuft. Nachdem aber AVM inzwischen sogar schon das TFFS für die Speicherung im NAND- anstelle von NOR- oder SPI-Flash umgemodelt hat, werden sicherlich künftig eher mehr als weniger Geräte mit NAND-Flash herauskommen und dann bietet es sich ja an (auch wegen des geringeren Preises beim NAND), daß man diesen "hot flash"-Mechanismus immer häufiger einsetzt (nur dann klappt auch das "volle Auto-Update"). So richtig kleine NAND-Flash-Chips sind ohnehin nicht zu bekommen, ich vermute mal, daß die jetzt schon in einigen Geräten verbauten 128 MB NAND gesamt eher das untere Ende der Fahnenstange bilden werden.
Wenn das dann bei den 48 MB-Partitionen bleibt (und die nicht verkleinert werden), sind die Filesystem-Partitionen nicht einmal halbvoll am Ende - und auf der anderen Seite riskiert man mit jedem entfernten AVM-Modul (solange es sich nicht mit Freetz in die Haare gerät) weiterhin, daß irgendwelche Abhängigkeiten bestehen, die dann zum Systemversagen führen ... ob das nun Telefonie oder WLAN oder NAS oder Gastnetz oder irgendetwas anderes ist. Echte Platzprobleme in Geräten mit 06.50+ (außer eben 7360/7390) sollte es eigentlich auf absehbare Zeit erst einmal nicht geben - wer mehr als die verfügbaren ~45 MB als SquashFS-Image braucht, kann immer noch auf "external" gehen und hat dann (nach heutigem Stand) noch mal zusätzlich irgendwas zwischen 15 und 20 MB zur Verfügung, wobei er sich das mit dem FRITZ!OS (in den FRITZ-Verzeichnissen) teilen muß. Aber dann kann man auch das "external"-Image einfach mal noch (optional) als SquashFS-Image umsetzen, für die 69 MB eines recht großen external-Images bei der 7390 ergab sich bei einem früheren Test noch eine Restgröße von knapp 21 MB mit LZMA1-Kompression, wie bei der 7390 üblich. Kriegen die NAND-Modelle alle den 3.10-Kernel, wird es mit LZMA2 noch etwas besser ... jedenfalls kriegt man in die 22 MB-Partition im NAND-Flash einer 7362SL schon mehr Daten hinein, als in jedes "normale SquashFS-Image" einer 7390 und das wäre ja immer noch der "Zusatzspeicher", falls es im yaffs2 eng wird.
Außerdem funktioniert so eine Änderung einer bestimmten Zeile, bei der diese um eine zusätzliche Bedingung mit der Abfrage einer FREETZ-Variablen bereichert wird, deutlich besser als irgendwelchen Code zu entfernen, weil selbst Verschiebungen dieser Zeile innerhalb der Datei oder zusätzlich eingefügte Zeilen im AVM-Code zwischen dem angepeilten "Beginn- und Ende-Marker" (möglichst noch mit Definitionen oder der Initialisierung von Variablen, die außerhalb weiterhin genutzt werden) für irgendwelche Löschaktionen erheblich seltener auftreten können bzw. dann öfter vollkommen egal sind.
So, wieder viel geschrieben, aber hoffentlich einiges an Für und Wider schon von Beginn an aufgezeigt und/oder entkräftet, spart vielleicht auch ein paar Round-Trips.
