[Erledigt] Platzprobleme im Freetz-Image (NOR-Box 7390) nach "version bumps"

[PeterPawn]

EDIT:
Lösung war (bei mir) dann doch sehr einfach: Aus irgendeinem (mir unerfindlichen) Grund war die Einstellung "FREETZ_CHECK_CHANGED" in der verwendeten .config nicht gesetzt und es handelte sich natürlich gerade nicht um eine "von Grund auf neue Installation" (sonst gäbe es das Versionsproblem ja ohnehin nicht). Mit einer frischen .config (oder eben manueller Kontrolle) sollte sich das "Problem" dann auch bei jedem anderen beheben lassen, die gesamten "Build system options" sind aber erst ab "Advanced" bei "user experience level" (EDIT: nope, heißt "competence level", gerade nachgelesen) sichtbar in der Konfiguration.

---

-
Nur für den Fall, daß es anderen ebenso ergeht, ein Hinweis meinerseits:

Ich habe auf der Basis eines älteren Build-Systems (Trunk-Version irgendwo aus dem Juli) zu Testzwecken ein neues Image erzeugen wollen, nachdem ich die Quellen auf CS 13439 aktualisiert hatte:

~/trunk_7390$ svn info
Path: .
Working Copy Root Path: /home/localuser/trunk_7390
URL: http://svn.freetz.org/trunk
Relative URL: ^/trunk
Repository Root: http://svn.freetz.org
Repository UUID: 149334a1-2f27-0410-a3b9-fc62619ac1e6
Revision: 13439
Node Kind: directory
Schedule: normal
Last Changed Author: er13
Last Changed Rev: 13439
Last Changed Date: 2015-10-24 22:26:16 +0200 (Sat, 24 Oct 2015)

Zwischenzeitlich sind ja einige Änderungen und auch einige neue Versionen für diverse Pakete hinzugekommen.

Dabei haben sich auch die Dateinamen einiger Libraries geändert und - solange man nicht für die betreffenden Pakete explizit (oder generell für alle) ein "distclean" ausführt - beim Zusammenstellen des Images werden alte und neue Versionen parallel aus "packages" nach "build/modified/filesystem" kopiert. Bei der Verarbeitung für "externals" werden dann aber nur die aktuellen Versionen der Libraries nach "build/modified/externals" verschoben, die älteren Versionen bleiben unter "build/modified/filesystem/usr/lib/freetz" stehen und blähen das root-SquashFS entsprechend auf. Bei mir waren das immerhin 6 recht große Bibliotheken (u.a. libgnutls/libgcrypt/libcurl) mit einer unkomprimierten Größe von ca. 4 MB, was im Ergebnis ein Image ergab, das um 1,7 MB zu groß war.

Es empfiehlt sich also, entweder noch einmal einen "Kontrollblick" in das Verzeichnis usr/lib/freetz eines fertigen Images zu werfen, ob dort noch irgendwelche "Leichen" liegen oder die Changesets aufmerksam zu verfolgen, damit man weiß, welche Pakete ggf. ein "distclean" benötigen oder gleich in den sauren Apfel zu beißen und nach einem "make distclean" einfach alles neu zu übersetzen.

Das Problem dieser Abhängigkeiten ist zwar generell bekannt, aber so mancher verwendet eben sein Build-System nur in recht großen Abständen und wenn man nicht (so wie in meinem Falle) die Grenzen seines Images systematisch bis zum letzten Byte ausreizen will, fallen solche älteren Artefakte vielleicht gar nicht auf beim Build und man ist dann eher versucht, durch zusätzliche Remove-Patches den benötigten Platz zu schaffen, obwohl es eigentlich gar nicht notwendig wäre. Das Problem betrifft in aller Regel auch nur die Libraries, da nur diese mit den Versionsnummern im Dateinamen arbeiten ... wurden also viele Libraries aktualisiert, ist die "Gefahr" solcher Überbleibsel besonders hoch. Man sieht es auch dem Buildprozess (bzw. dessen Ausgabe) nicht an (egal wie "geschwätzig" man es haben will), daß diese Reste existieren ... jedenfalls solange nicht, wie das resultierende SquashFS-Dateisystem die "Grenzen" des verfügbaren Speichers nicht überschreitet.

 

[er13]

solange man nicht für die betreffenden Pakete explizit (oder generell für alle) ein "distclean" ausführt - beim Zusammenstellen des Images werden alte und neue Versionen parallel aus "packages" nach "build/modified/filesystem" kopiert.

Wir hatten mal ein Ticket zu dem Thema. Das Problem kann nur dann weiterhin auftreten, wenn sich der Name der Library grundlegend ändert (nicht die Versionsnummer im Namen, sondern wirklich der grundlegende Aufbau des Namens) bzw. wenn eine Library komplett rausfliegt, so wie das mit gnutls-extra der Fall war. D.h. das mit libgnutls könnte ich erklären, für libgcrypt/libcurl hätte ich jedoch keine Erklärung, es sei denn Du hast aktiv/bewusst FREETZ_CHECK_CHANGED abgeschaltet.

 

[PeterPawn]

es sei denn Du hast aktiv/bewusst FREETZ_CHECK_CHANGED abgeschaltet.

Das Ticket hatte ich noch schwach in Erinnerung ... auch die Tatsache, daß es gefixt sein sollte. Daher war ich auch etwas verblüfft.

Jedenfalls ist die Einstellung (ohne aktive/bewußte Mitwirkung meinerseits) nicht gesetzt:

~/trunk_7390$ grep CHECK_CHANGE .config
# FREETZ_CHECK_CHANGED is not set

Denkbar wäre es, daß sie bei irgendeinem (unaufmerksamen) "make oldconfig" auf diesem Wert landete - inzwischen habe ich auch die Variable im Menü gefunden (wenn man den Namen kennt, ist es ja wieder easy, den hatte ich im Ticket nicht gefunden), das "Force package clean" ist (logischerweise, wenn man den Wert in der .config sieht) tatsächlich ausgeschaltet.

Das ist - wie in #1 angedeutet - eine der "Test-Installationen" von Freetz und die läuft unter "user competence = beginner".

Meine Idee dazu wäre es jetzt gewesen, daß beim Hinzufügen dieser Variablen zur Konfiguration beim "make oldconfig" tatsächlich irgendwie automatisch "n" übernommen wurde ... aber selbst die Historie der "build-system.in" und/oder der "building.in" läßt da (zumindest bei dem was ich sehen kann) keinen Spielraum für solche Spekulationen - in der build-system.in ist der Standard ganz klar "y".

Also irgendein Problem auf meinem eigenen System, damit dann logischerweise erledigt.

#1 markiere ich, füge auch noch einen Hinweis auf die Variable hinzu als Tipp für eine erste Anlaufstelle bei ähnlichen Problemen - vielleicht gibt es ja noch mehr Installationen, wo das irgendwie schiefgelaufen ist.