make-kpkg: unresolved symbols

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
lobo
Beiträge: 180
Registriert: 27.01.2002 21:48:08
Lizenz eigener Beiträge: GNU General Public License

make-kpkg: unresolved symbols

Beitrag von lobo » 28.12.2004 03:51:47

Hallo,

beim kompillieren eines Kernels mit make-kpkg erscheint bei den Modulen ide-core und xfs immer "unresolved symbols". Woher kommt diese Meldung und wie kann ich das Problem lösen?

System:

OS: Debian GNU/Linux SID
gcc: 2.95 / 3.3.5 (schon mit beiden getestet)
Kernel: linux 2.4.28 (vanilla), cramfs Patch, GRSecurity 2.0.2-2.4.28
verwendete Konfiguration: Angepasste Konfiguration vom Debian kernel-image-2.4.27-1-686
RootFS: ext3


Befehl:
make-kpkg --rootcmd fakeroot --initrd kernel_image

Code: Alles auswählen

depmod: *** Unresolved symbols in /home/jochen/tmp/kernel/linux-2.4.28/debian/tmp-image/lib/modules/2.4.28-grsec.rb.p3/kernel/drivers/ide/ide-core.o
depmod:         init_cmd640_vlb
depmod: *** Unresolved symbols in /home/jochen/tmp/kernel/linux-2.4.28/debian/tmp-image/lib/modules/2.4.28-grsec.rb.p3/kernel/fs/xfs/xfs.o
Das Problem lässt sich sicher beheben, wenn ich das IDE Modul fest einkompilliere oder initrd nicht verwende, das ist aber keine Lösung, da der Kernel auf Systemen mit S-ATA, IDE und SCSI Platten laufen soll.

Ich habe auch schon mehrmals make clean, make-kpkg clean, make mrproper vor dem kompillieren probiert ;-)

Hoffentlich kann mir jemand helfen, bei meiner Google Rundreise habe ich nur gelesen "initrd deaktivieren", "ext3 und ide fest einkompillieren", aber das kann keine gescheite Lösung sein. Der Debian Kernel funktioniert ja auch, von dem ich die Konfiguration kopiert habe, deswegen ist es mir schleierhaft woher der Fehler kommt.

Gruss

Jochen
Zuletzt geändert von lobo am 30.12.2004 01:12:32, insgesamt 1-mal geändert.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.12.2004 16:06:27

Du kannst entweder "CMD640 chipset/bugfix support" CONFIG_BLK_DEV_CMD640 ausschalten oder ide_core fix in den Kernel integrieren.
Das sollte das unresolved symbol "init_cmd640_vlb" fixen.

Die Ausgabe von make-kpkg wurde leider abgeschnitten, daher gibt es möglicherweise noch weitere "unresolved symbols".

lobo
Beiträge: 180
Registriert: 27.01.2002 21:48:08
Lizenz eigener Beiträge: GNU General Public License

Beitrag von lobo » 30.12.2004 00:14:02

gms hat geschrieben:Du kannst entweder "CMD640 chipset/bugfix support" CONFIG_BLK_DEV_CMD640 ausschalten oder ide_core fix in den Kernel integrieren.
Das sollte das unresolved symbol "init_cmd640_vlb" fixen.
CONFIG_BLK_DEV_CMD640 habe ich deaktiviert, bekomme aber immer noch bei ide-core und xfs die unresolved symbols. So wie ich das sehe ist aber CMD640 auch nicht schuld daran, denn die unresolved Symbols erscheinen ja bei ide-core und xfs. Wenn ich IDE fest einkompillieren geht es, aber das ist ja nicht die Lösung. Ich will unbedingt einen sicheren und modularen Standard Kernel *mitdenfüssenaufdenbodenstampf* :D Im Debian Kernel sind die sachen auch als Module, deswegen verstehe ich nicht warum es bei mir nicht funktioniert.
gms hat geschrieben:Die Ausgabe von make-kpkg wurde leider abgeschnitten, daher gibt es möglicherweise noch weitere "unresolved symbols".
Nein, es waren keine weitern "unresolved symbols", nur ide-core und xfs.

Gruss

Jochen

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 30.12.2004 00:27:54

lobo hat geschrieben:Nein, es waren keine weitern "unresolved symbols", nur ide-core und xfs.
ide-core und xfs sind die Module in denen "unresolved symbols" auftreten.
Anders ausgedrückt: In ide-core und xfs werden irgendwelche Symbole referenziert,
deren Definition nicht gefunden werden kann. (in keinem Modul und auch nicht im Kernelimage selber).

Und genau diese Symbole würden mich interessieren.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 30.12.2004 00:50:16

Woher hast du den cramfs und grsecurity patch ? Ich werde den Compiler einmal bei mir anwerfen, möchte aber möglichst die gleiche Ausgangssituation verwenden.

lobo
Beiträge: 180
Registriert: 27.01.2002 21:48:08
Lizenz eigener Beiträge: GNU General Public License

Beitrag von lobo » 30.12.2004 01:27:44

Sorry, ich muss mich entschuldigen, das entfernen von CONFIG_BLK_DEV_CMD640 hat doch geholfen. Ich hab irgendwie zu viele Kernel-Images hier. Dass es "unresolved symbols" produziert, könnte vielleicht auf den GRSecurity Patch zurückzuführen sein, da die ohne den Patch bei ide-core mit aktiviertem CMD640 nicht erscheinen.

Jetzt macht nur noch xfs Probleme. Ein Grossteil der letzten Zeilen vom Kernel Build habe ich hier http://www.roastbyte.net/grsec/xfs_unresolved.txt

Danke für die Hilfe

Jochen

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 30.12.2004 13:28:49

in deinem Logfile habe ich das unresolved symbol gefunden:

Code: Alles auswählen

depmod: *** Unresolved symbols in /home/jochen/tmp/kernel/linux-2.4.28/debian/tm p-image/lib/modules/2.4.28-grsec.rb.p3/kernel/fs/xfs/xfs.o
depmod:         protection_map
D.h.: im Modul xfs wird das Symbol "protection_map" referenziert, es wird aber keine Definition dieses Symbols gefunden.

Durch den GRSecurity Patch werden diese Zeilen in xfs_file.c eingefügt:

Code: Alles auswählen

+#ifdef CONFIG_GRKERNSEC_PAX_PAGEEXEC
+       if (current->flags & PF_PAX_PAGEEXEC)
+               vma->vm_page_prot = protection_map[vma->vm_flags & 0x0f];
+#endif
Dieser Patch ist also, zumindestens wenn CONFIG_GRKERNSEC_PAX_PAGEEXEC und xfs ausgewählt wurde, fehlerhaft.
Die einfachste Lösung (bereits getestet) ist daher CONFIG_GRKERNSEC_PAX_PAGEEXEC zu entfernen.


Hier ist die Beschreibung zu dieser Einstellung:

Code: Alles auswählen

+Paging based non-executable pages
+CONFIG_GRKERNSEC_PAX_PAGEEXEC
+  This implementation is based on the paging feature of the CPU.
+  On i386 it has a variable performance impact on applications
+  depending on their memory usage pattern.  You should carefully
+  test your applications before using this feature in production.
+  On alpha, parisc, sparc and sparc64 there is no performance
+  impact.  On ppc there is a slight performance impact.

lobo
Beiträge: 180
Registriert: 27.01.2002 21:48:08
Lizenz eigener Beiträge: GNU General Public License

Beitrag von lobo » 30.12.2004 16:40:59

Kudos to gms :D

Vielen Dank, dann blicke ich da jetzt wenigstens mal durch. Dann werde ich wohl xfs deaktivieren müssen, was nicht ganz so schlimm ist, da ich auf allen Server ext3 verwende.

Gruss

Jochen

Antworten