freetz-devel-4093M => 4095M: 977152 bytes free => 497920 bytes free (468 KB less)

[ao]

Hallo,

vorhin hatte ich ein 4093M-Image gebaut, und es waren noch 977152 Bytes frei (max: 7798784).
Nun habe ich ein 4095M-Image gebaut, und es sind nur noch 497920 Bytes frei (max: 7798784), also 479232 Bytes (468 KB) weniger.
Und das, obwohl ich außer "make menuconfig" zwischendurch nichts anderes gemacht habe, also keine Veränderungen bzgl. Pakete, Patches oder sonstwas.
Heisst das nun, dass 4095M 468 KB mehr Platz als 4093M benötigt?

 

[er13]

Na ja Du hast weder mc noch glib-* noch openvpn noch php im Image, also scheiden eigentlich alle Changesets 4093-4096 aus. Überleg', ob Du vielleicht doch sonst was gemacht hast, z.B. falsche .config angehängt oder von 4083 auf 4095 upgedatet...

 

[ao]

Nein, definitiv nicht. Ich habe noch für beide FW-Versionen die Image-Datei selbst sowie die External-Datei im "images" Folder liegen.
Die "free" Größe der 4093M hatte ich mir noch vor dem "make" der 4095M auf einen Zettel notiert.
Außerdem hatte ich schon öfters das Gefühl, dass ein simples, erneutes Aufrufen von "make menuconfig" und "make" plötzlich zu anderen "free" Werten geführt hat. Ich hatte auch schon einmal einen Thread dazu gestartet (finde ich momentan nicht), dann aber mangels Zeit zum Reproduzieren des Phänomens das Thema aufgegeben. Nun scheint es mich aber wieder einzuholen...
Kann das vielleicht sonst noch jemand nachvollziehen?

 

[er13]

Außerdem hatte ich schon öfters das Gefühl, dass ein simples, erneutes Aufrufen von "make menuconfig" und "make" plötzlich zu anderen "free" Werten geführt hat. Kann das vielleicht sonst noch jemand nachvollziehen?

Welche Build-Umgebung nutzt Du? Verschlüsselte Home-Partition? Lies Dir mal schnell diesen Thread. Gibt es bei im modified-Folder Dateien der Länge 0, dies könnte dieses "mal kleiner mal größer" erklären.

Die "free" Größe der 4093M hatte ich mir noch vor dem "make" der 4095M auf einen Zettel notiert.

na hoffentlich nicht auf einem echten Zettel ich übersetze immer so make 2>&1 | tee -a make.log und dann brauche ich nichts zu notieren

 

[olistudent]

Ich hab jetzt deine .config bauen lassen.
Ergebnis:

  kernel image size: 6781952 (max: 7798784, free: 1016832)

Da muss ich wohl erst nochmal vergleichen, ob die wirklich identisch sind...

MfG Oliver

 

[Nimrod]

Obwohl es vielleicht unwahrscheinlich ist dass es hilft, hast du mal ein make config-clean-deps getestet? Man weiß ja nie ;-)

 

[ao]

@er13:
Danke für den Tipp zum Mitloggen, mache ich ab und zu auch so. In diesem Fall musste ich ja nur ein paar Ziffern notieren.

@Nimrod:
"make config-clean-deps" mache ich sonst aus Gewohnheit und Sicherheit immer, wenn ich in menuconfig etwas umgestellt habe. Da das aber hier wirklich nicht der Fall war und ich "make menuconfig" nur noch einmal vor dem "make" von 4095M aufgerufen hatte (damit neue Pakete prinzipiell wählbar sind - ich habe aber die Pakete und auch sonst nichts angefasst), hatte ich auch auf ein "make config-clean-deps" verzichtet.
Meine FW baue ich unter Ubuntu 8.04, das in einer VM läuft (ohne Verschlüsselung).

@Oliver:
Wenn Du mit meiner .config baust, müsste doch am Ende dasselbe Image, dieselbe external-Datei mit denselben Größen und demselben freien Speicher entstehen. Oder hängt das evtl. tatsächlich von der Build-Umgebung ab?

 

[Silent-Tears]

Oliver kann natürlich nur ein generisches Image bauen ohne deine Modifizierungen, da können schon - je nachdem, was du da fabriziert hast - einige K zusammenkommen.

Ich hab die Images mal nachgebaut in Revision 4093 und Revision 4095, jeweils mit deiner .config und einem "make oldconfig" dazwischen.

4093: kernel image size: 6805248 (max: 7798784, free: 993536)
4095: kernel image size: 6805248 (max: 7798784, free: 993536)
4098: kernel image size: 6805248 (max: 7798784, free: 993536)

Die beiden grössen sind identisch zwischen den beiden Revisionen, allerdings hab ich da tatsächlich schon ne andere Grösse als Oliver, was dann tatsächlich nur aufs Buildsystem zurückzuführen sein kann, wenn wir sonst die komplett identischen Vorraussetzungen haben.

 

[er13]

Kann es irgendwie damit zusammenhängen, in welcher Reihenfolge mksquashfs die Dateien dem Filesystem-Image hinzufügt (wobei bei mir scheint diese immer alphabetisch zu sein), sollen wir diese vielleicht explizit mittels -sort steuern?

@ao: vergleiche mal build/modified/filesystem.log von zwei Builds, wo sich die Größen am Ende unterscheiden

 

[RalfFriedl]

Unterschiede in der Reihenfolge sollten keine großen Unterschiede machen, wenn überhaupt. Und wie würdest Du die Reihenfolge mit sort steuern wollen? Kennst Du eine Reihenfolge, die bessere Ergebnisse bringt?

 

[olistudent]

Mit einem frischen Checkout komme ich auf das gleiche Ergebnis wie Lars. Vorher hatte ich Unterschiede in der uClibc, manchen Modulen und der busybox.

  kernel image size: 6805248 (max: 7798784, free: 993536)

MfG Oliver

 

[Silent-Tears]

Gut, also sind da die gleichen WErte zu erwarten. Wir allerdings glaub ich haben beide Ubuntu, oder Oliver?

 

[er13]

@Ralf: eine bessere Reihenfolge kenne ich nicht, ich habe nur vermutet, dass diese vielleicht nicht deterministisch ist (wenn man über die Dateien eines Verzeichnisses iteriert, bekommt man diese bekanntlich nicht sortiert, sondern in der Reihenfolge wie sie angelegt wurden). Mit -sort könnte man sicherstellen, dass die Reihenfolge immer dieselbe ist, dies scheint aber doch nicht notwendig zu sein.

 

[ao]

Sorry, Ihr Gurus, ich verstehe z.T. nicht wirklich etwas von der Materie.
Was kann ich - neben dem o.g. Vorschlag bzgl. der Log-Files - sonst noch tun?

Prinzipiell geht es mir um folgendes:

Wie verhindere ich, dass durch den bloßen Upgrade von einer zur (über)nächsten Version ohne Änderungen der Patches, Pakete etc. plötzlich deutlich weniger Platz frei ist?

Soll ich statt "make menuconfig" dann besser "make oldconfig" aufrufen?
Was ist denn da der Unterschied im Vgl. zu meinem (bisherigen) Vorgehen?
(also "make menuconfig", keine Änderungen => save changes/ exit)

Neben meinem Anliegen besteht offenbar auch ein Interesse, die genauen Ursachen für Größenabweichungen zu erkennen, festzustellen, ob/ inwieweit das von Relevanz ist und ggf. Lösungen zu finden. Auch hierzu kann ich gerne noch etwas liefern (Logs o.ä., s.o.), brauche dazu aber noch etwas mehr Anleitung, da ich mich zwar schon länger mit Freetz beschäftige, aber leider doch nicht allzusehr unter die Haube schauen konnte.

 

[RalfFriedl]

Wie verhindere ich, dass durch den bloßen Upgrade von einer zur (über)nächsten Version ohne Änderungen der Patches, Pakete etc. plötzlich deutlich weniger Platz frei ist?

Indem Du verhinderst, daß AVM die (über)nächsten Version größer macht

Soll ich statt "make menuconfig" dann besser "make oldconfig" aufrufen?

Der Vorteil von oldconfig ist, daß man sieht, welche Optionen neu dazu gekommen sind. In menuconfig werden diese zwar auch mit NEW angezeigt, aber dazu müßtest Du in allen Untermenüs danach suchen. Wenn es Dich aber nicht interessiert und Du mit der Default-Auswahl einverstanden bist, ist das Ergebnis das gleiche.

 

[olistudent]

Wenn dich wirklich interessiert wo der Größenunterschied ist, dann musst du die 2 Images wieder auspacken.

tar xf image1
mv var/tmp/kernel.image .
rm -rf var
tools/find-squashfs kernel.image
tools/unsquashfs3-lzma kernel.raw

So ungefähr...

Dann lässt du mit "ls -asR image1 > image1.log" eine Datei vom Image-Inhalt erstellen. Das gleiche für das andere Image. Jetzt kannst du mit "diff -burN image1.log image2.log > image.diff" die Unterschiede in eine Datei schreiben lassen.

MfG Oliver

 

[ao]

Indem Du verhinderst, daß AVM die (über)nächsten Version größer macht

Sehr witzig, Ralf! Ich meinte natürlich die Freetz-Versionen, nicht die von AVM.
Danke für die Erklärung zu "oldconfig"!

@Oliver:
Interessante Idee, danke. Alternativ ginge doch auch ein rekursiver Vergleich der ganzen Verzeichnisse mittels meld.
Welche Build-Umgebung nutzt Du? Ubuntu?

 

[Silent-Tears]

Oliver nutzt - ebenso wie ich - Ubuntu. Und wir haben echt die selbe Imagegrösse.