[gelöst] /lib/modules/linux-3.16 > 2GB?

[matman]

Hallo, ich wollte mal was ausprobieren, weil in meiner speziell auf meine Hardware zugeschnittenen Kernel .config was nicht zu stimmen scheint. Also habe ich einfach mal die .config vom Standardkernel (config-3.16.0-4-amd64) in den Ordner vom Vanilla Kernel 2.16.7 kopiert und ein make oldconfig ausgeführt. Nur wenige zusätzliche Treiber waren in 3.16.7, die ich annehmen/ablehnen musste. Und dann wollte ich wissen, ob das Ergebnis quasi dem Standardkernel entspricht, bevor ich Änderungen an der Konfiguration vornehme. Dazu habe ich folgendes ausgeführt:

Code: Alles auswählen

make modules
make bzImage
make modules_install
update-initramfs etc.

Und dann hatte ich mal aus reiner Neugier mit du -h die Größen der Ordner /lib/modules/3.16.0-4-amd64 mit /lib/modules/3.16.7 verglichen und war doch recht erschrocken, als ich den Unterschied sah: Der Modul-Ordner vom Standardkernel ist 162 MB groß, der von meinem selbst kompilierten ganze 2,2GB. Die initrd.img von meinem Kernel ist ca. 10 mal so groß wie die vom Standardkernel. System.map und vmlinuz dagegen sind in etwa gleich groß.

Die Module betreffend ist das aber nun wirklich ein gigantischer Unterschied. Wenn ich da mit diversen Versionen experimentiern will habe ich ja bald keinen Platz mehr auf der HD. Bisher hatte ich bei meinen selbst konfigurierten Kernels was um die 12 MB im Ordner der Module. Woher könnten diese wahnsinnigen 2,2GB kommen?

Ich habe doch nur die Konfiguration vom Debian-Kernel genommen, der ebenfalls mit erheblich weniger Speicherplatz auskommt. Ich kann das jetzt nicht im geringsten nachvollziehen. Hat jemand deine Idee?

[eggy]

Evtl mit Debugsymbolen kompiliert? Was sagt nen diff der configs?

[matman]

Die diffs direkt nach erster Kompilierung habe ich nicht mehr. Nachdem ich noch Ext2, Ext3 als Module hinzufügte und IO/Sheduler zu Deadline änderte (ich glaube mehr Änderungen waren das nicht) habe ich jetzt diese diff (3.16.7-nt.04 ist meine config):

• 39101

Ich kann da jetzt nichts dran erkennen. Ich könnte mal noch explizit per menuconfig die Debugeinstellungen überprüfen. Oder ich nehme erstmal die Sourcen aus dem Debian-Repo und schau mal, ob da das selbe passiert. Nur leider habe ich da heute keine Zeit mehr dafür.

[matman]

So, auf geht es in die nächste Runde. Was ich noch hinzufügen kann: Die selbstkompilierte Variante des Kernels lässt sich nicht starten bzw. beim Booten kommen mehrere Meldungen endend auf "invalid module format".

Also irgendwas ist da wohl bei den Modulen gehörig schief gelaufen. Mal sehen, ob ich die Ursache heute finde

[matman]

Ich habe noch einige aktuelle Infos:

Mir kommt das mittlerweile so vor, als gäbe es in der vom Jessie mitgelieferten Konfigurationsdatei für den Standardkernel einen Bug. Ich habe eben mal einfach nur die Standardkonfig in die Kernelsourcen aus den Jessie-Repos übernommen und ohne jegliche Veränderung kompiliert und installiert. Und dann habe ich das mal verglichen mit der Installation vom Standardkernel, die per deb Paket installiert wurde. Fazit:

Das was ich kompiliert habe ich etwa 13 mal so Groß, wie das was per deb Paket ins System kam. Nur mal so als Beispiel betrachtet am Modul emu10k1:

Das hier stammt aus dem deb Paket:

Code: Alles auswählen

ls -al kernel/sound/pci/emu10k1/snd-emu10k1.ko
-rw-r--r-- 1 root root 251776 Jan 17 22:29 kernel/sound/pci/emu10k1/snd-emu10k1.ko

Und das hier entstand durch mein Kompilieren:

Code: Alles auswählen

ls -al kernel/sound/pci/emu10k1/snd-emu10k1.ko
-rw-r--r-- 1 root root 3259056 Jan 25 12:45 kernel/sound/pci/emu10k1/snd-emu10k1.ko

Das dürfte doch eigentlich gar nicht sein, oder?

Ich weiß nicht, ob es einen Unterschied machen würde, wenn man anstatt make modules/make bzImage das von Debian bereitgestellte Tool fakeroot make-kpkg benutzen würde. Ich würde ja mal vermuten, das da am Ende das gleiche dabei heraus kommt, zumindest was vmlinuz und die Module angeht.

Und wie schon erwähnt meckert der von mir kompilierte Kernel ja auch rum, das ein ungültiges Format der Module vorliegt. Dürfte doch eigentlich gar nicht sein, wenn man auf ner AMD64-CPU mit der Konfiguration CONFIG_X86_64=y kompiliert, das da die falschen Module kompiliert werden. Was kann da nur los sein?

Die diff der .config Dateien weiter oben kann man getrost vergessen, weil das Problem mit Sicherheit von der Standardconfig stammt.

[MSfree]

Code: Alles auswählen

ls -al kernel/sound/pci/emu10k1/snd-emu10k1.ko
-rw-r--r-- 1 root root 251776 Jan 17 22:29 kernel/sound/pci/emu10k1/snd-emu10k1.ko

Und das hier entstand durch mein Kompilieren:

Code: Alles auswählen

ls -al kernel/sound/pci/emu10k1/snd-emu10k1.ko
-rw-r--r-- 1 root root 3259056 Jan 25 12:45 kernel/sound/pci/emu10k1/snd-emu10k1.ko

Das dürfte doch eigentlich gar nicht sein, oder?

Gibt es auf deinem Rechner den Befehl strip?

Wenn nein, fehlt eine Komponente auf deinem Entwicklungssystem, wobei ich gerade nicht weiß, welche?

Wenn ja, führ mal strip kernel/sound/pci/emu10k1/snd-emu10k1.ko aus und vergleiche anschließend die Größen noch einmal.

Ich denke, daß in deinen Kompilaten noch die Symboltabellen vorhanden sind, die man mit strip entfernen kann. Ich hätte allerdings erwartet, daß make modules zumindest im optimierten Modus die Symbole bereits entfernen sollte (es sei denn, strip fehlt, siehe oben).

[KBDCALLS]

Am Strippen kanns nicht liegen. Sieht man sich nämlich die Kernelpakete an mit und ohne dpg , dann sind in beiden die Module ungestrippt.

Ist das Paket binutils installiert dann hat man auch automatisch strip,

[MSfree]

Am Strippen kanns nicht liegen.

Davon bin ich noch nicht überzeugt. Für mich hört sich das schwer nach irgendwelchem Symboltabellen oder Debugtabellen an, die man mit strip auch individuell entfernen kann.

Vielleicht hilft es ja, die Symboltabellen mit readelf anhand der snd-emu10k1.ko, das .ko von der Debianinstallation mit der selbstkompilierten Version zu vergleichen.

[KBDCALLS]

Hab eher die Kernelkonfig in Verdacht. Und zwar Kernel Hacking Denn mir ist mal was ähnliches mit einem 2.6.xx Kernel passiert.

Da würde ich auf jeden Fall mal suchen.

Ps:

Ein Test hat ergeben das die Module bis zu 10 mal größer werden können, wenn alles aktiviert wird.

[MSfree]

Hab eher die Kernelkonfig in Verdacht. Und zwar Kernel Hacking Denn mir ist mal was ähnliches mit einem 2.6.xx Kernel passiert.

Das widerspricht sich ja nicht mit meinem Verdacht, daß da die Symboltabellen mit reinkompiliert werden. Wie gesagt, die kann man mit strip loswerden.

[matman]

Also ich habe eben mal strip auf das von mir kompilierte emu10k1.ko angewendet. Ergebnis: das Modul emu10k1.ko hat jetzt eine größe von 136072 Bytes, ist nun also nur noch ca. halb so Groß, wie das Modul aus dem deb Paket.

Damit sind wir wohl schonmal auf der richtigen Spur. Aber was macht man da am besten? Manuell alle Module ändern erfordert wohl ein Skript, das alle .ko Dateien sucht uns abarbeitet. Denn von Hand dauert das vermutlich einige Tage

Und ob man dann am Ende das richtige Modulformat hat, das ist woh auch noch unklar. Gut wäre außerdem, wenn gleich alles korrekt kompiliert wird. denn so wie es jetzt ist kommt ja noch hinzu, dass alleine der Sourcetree 8,6 GB Plattenplatz belegt. Ich glaube sonst waren das nach dem Kompilieren maximal 2 GB. Eine derartige Ressourcenverschwendung wollte ich mir nicht gerade leisten

Naja, heute ist mir das zu spät, mich da noch auf die Suche zu machen. Ich kann ja morgen mal den Bereich Kernel-Hacking mit der config aus meinem alten System vergleichen. Damit klappte es immerhin problemlos, auch den 3.16er Kernel zu so zu kompilieren, das die Module normal waren. Und vielleicht hat ja noch jemand eine Idee...

[MSfree]

Also ich habe eben mal strip auf das von mir kompilierte emu10k1.ko angewendet. Ergebnis: das Modul emu10k1.ko hat jetzt eine größe von 136072 Bytes, ist nun also nur noch ca. halb so Groß, wie das Modul aus dem deb Paket.

Und damit hat es die Größe der originalen Moduls nachdem man dieses ebenfalls stript.

Manuell alle Module ändern erfordert wohl ein Skript

Nein, nur einen einzigen Befehl auf der Kommandozeile:

find /lib/modules/`uname -r` -name \*.ko -exec strip {} \;

Und ob man dann am Ende das richtige Modulformat hat, das ist woh auch noch unklar.

Das Format der Module, wie übrigens aller anderen shared Objects und Executables ist ELF, daran ändert strip nichts. Es entfernt lediglich alle unnötigen Symbolinformationen, mit deren Hilfe man Software besser debuggen kann. Um ganz sicher zu gehen, könntest du das gestripte Modul mit modprobe ja mal laden, das sollte eigentlich funktionieren.

Gut wäre außerdem, wenn gleich alles korrekt kompiliert wird.

Das könnte in der Tat daran liegen, wie KBDCALLS schon erwähnt hat, daß du in der Kernelkonfiguration "Kernel Hacking" ausgewählt hast. Das baut dann diese erweiterten Symboltabellen in Kernel und Module ein.

[matman]

Jetzt war mir noch ne Grippe dazwischengefunkt, aber heute habe ich es dann endlich mal geschafft:

Alles aus "Kernel hacking" lässt sich nicht so einfach deaktivieren. Leider wird einiges davon durch andere Module oder Features zwingend aktiviert. Aber diese Optionen konnte ich deaktivieren:

Code: Alles auswählen

ONFIG_PRINTK_TIME is not set
CONFIG_BOOT_PRINTK_DELAY is not set
CONFIG_DEBUG_INFO is not set
CONFIG_STRIP_ASM_SYMS is not set
CONFIG_DEBUG_FS is not set
CONFIG_MAGIC_SYSRQ is not set
CONFIG_KMEMCHECK is not set
CONFIG_LOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG is not set
CONFIG_TIMER_STATS is not set
CONFIG_FTRACE is not set
CONFIG_BRANCH_PROFILE_NONE is not set
CONFIG_DEBUG_SET_MODULE_RONX is not set
CONFIG_OPTIMIZE_INLINING is not set

Es blieb dann nur noch das Problem mit dem 'invalid module format'. Ich machte mich zunächst danach auf die Suche, ob irgendwas mit der Versionsnummer nicht übereinstimmt, konnte aber nichts finden. Glücklicherweise kam mir dann schnell die Idee, das ich gewohnheitsgemäß schon recht lange mit 'make bzImage' kompiliere, also mit bzip2 Kompression, während in der Standardkonfiguration von Debian 'CONFIG_KERNEL_BZIP2 is not set' eingestellt ist. Nachdem ich das entsprächend änderte, passen nun auch die Module.

Danke auch für eure Mithilfe

[KBDCALLS]

Sehe ich das richtig das du nur die Module neu kompiliert hast? invalid module format deutet eingentlich darauf hin das laufender Kernel und Module mit unterschiedlichen Kompilerversionen kompiliert sind.

[matman]

Ich hoffe, ich habe deine Frage richtig verstanden. Kompiliert habe ich die Module & den Kernel.

Allerdings muss ich noch hinzufügen, das meine Änderung auf CONFIG_KERNEL_BZIP2=y das Problem mit dem invalid module format nicht löste. Irgendwie waren die Module plötzlich passend nach dem zweiten Kompilieren (stage 2, oder auch #2 im Versions-String).

Wenn ich dann aber im Makefile EXTRAVERSION ändere, geht die Schose von vorne los. Das Ändern von 'CONFIG_MODVERSIONS=y' zu 'CONFIG_MODVERSIONS is not set' hat diesem Spuk nun endgültig ein Ende gesetzt.

Ich fand heraus, das dmesg etwas mehr Infos preisgab als das simple "invalid module format" aus der Konsole. Dort war nämlich in etwa das hier zu lesen "modprobe: unknown symbol in module xyz". Danach gegoogelt führte mich zu diesem recht gut aufklärenden Artikel: http://www.isely.net/pipermail/pvrusb2/ ... 00281.html

Jetzt ist zwar noch nicht ganz klar, warum es zu dem Problem mit dem "invalid module format" überhaupt kommen konnte, da ich ja aus dem Sourcetree 3.16.7 heraus kompilierte und entsprechend die Version 3.16.7 erzeugte und sonst nichts weiter. Aber so wie das für mich aussieht, kapiert der "make Vorgang" nicht so richtig, das ich immer im Makefile die Variable EXTRAVERSION mit einem Wert versehe, um später verschiedene Kernel-Konfigurationen booten zu können. In /lib/modules sowie im Dateiname von vmlinuz ist der String aus EXTRAVERSION enthalten. Aber scheinbar kommt beim ersten Druchlauf des Kompilers dieser String nicht bei diesem CRC-Gedönse (Siehe Artikel aus Absatz oben) an.

[KBDCALLS]

Das mit den unterschiedlichen Compilern war eine Möglichkeit. Sobald ich an der Version was ändere , und seis nur die Extra-Version im make-file des Kernels , werden die Module als nicht passend zum laufenden Kernel angesehn. Die Kernelversion wird auch im Modul vermerkt.

Zum Beispiel beim ext4 Modul

• Code: Alles auswählen

  modinfo -F vermagic ext4
  4.3.0-0.bpo.1-amd64 SMP mod_unload modversions 

• Code: Alles auswählen

  modinfo -F vermagic /lib/modules/4.2.0-0.bpo.1-amd64/misc/vboxdrv.ko 
  4.2.0-0.bpo.1-amd64 SMP mod_unload modversions