PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : unresolved symbols


24.07.00, 21:13
hallo
also mein problem ist folgendes:
ich habe jetzt RedHat 6.2 installiert und mir dann einen eigenen modularisierten Kernel gebaut (für atapi brenner ...). das hab ich so gemacht wie schon bei allen anderen distributionen.
jetzt bekomme ich beim booten immer ne latte *aller* module mit ner "unresolved symbols" meldung (bei depmod -a genau das gleiche) und kein modul kann mehr geladen werden!
ich dachte ja eigentlich die meldung hat was mit modulabhängigkeiten zu tun, aber bei mir geht ja kein einziges modul (bei lsmod wird nichts aufgeführt).

Danke im voraus


------------------
Searching
Seek And Destroy

Backi
24.07.00, 21:24
Welche Kernelversion hattest Du vorher und welche hast Du jetzt?
Hast Du vielleicht vergessen, die initrd upzudaten?

Gruß,
Backi

25.07.00, 15:02
ich habe kernelversion 2.2.14
ich habe den quellcode von der redhat cd genommen

was muß ich in der initrd denn updaten? da hab ich noch nie was gemacht nachdem ich nen neuen kernel erstellt habe.



------------------
Searching
Seek And Destroy

Backi
25.07.00, 15:39
Der RedHat-Kernel hat die Versionsnummer 2.2.14-5.0 und speichert seine Module im Verzeichnis /lib/modules/2.2.14-5.0. Wenn Du jetzt einen neuen Kernel mit der gleichen Versionsnummer, aber (höchstwahrscheinlich) mit wesentlich weniger Modulen baust, dann findet depmod beim Systemstart haufenweise Module, die der Kernel gar nicht kennt, da Du sie bei der Kernelkonfiguration abgewählt hast.
Ich würde Dir raten, in der Datei /usr/src/linux/Makefile die EXTRAVERSION von -5.0 auf z.B. -6 zu setzen. Dann machst Du wie gewohnt make dep clean bzImage modules modules_install. Die neuen Module landen dann im Verzeichnis /lib/modules/2.2.14-6
RedHat verwendet beim Starten standardmäßig eine Initrd um evtl. zum Booten benötigte Module schon vor dem Mounten des /-Verzeichnisses zur Verfügung zu haben. Wenn Du einen neuen Kernel baust, ist es ratsam, diese initrd ebenfalls auf den neuesten Stand zu bringen. Dazu gibt es den Befehl mkinitrd. Ein "mkinitrd /boot/initrd-2.2.14-6.img 2.2.14-6" erzeugt eine neue initrd für den Kernel 2.2.14-6. Diese initrd mußt Du nur noch in Lilo aufnehmen. In der /etc/lilo.conf hat RedHat die Einträge für den Original-Kernel gemacht. Einfach an die neue Versionsnummer anpassen.

Gruß,
Backi

25.07.00, 15:47
danke
ich werd es mal probieren.


------------------
Searching
Seek And Destroy

25.07.00, 18:38
habe jetzt extraverionsnummer auf 6.0 gestellt und neu kompiliert.
hat noch nix gebracht. dann wollte ich mkinitrd ausführen, aber es bricht mit der meldung "All loopback devices are busy" (oder so ähnlich) ab. dafür muß ich wohl erst das loopback modul laden http://www.linuxforen.de/ubb/frown.gif, aber das geht ja nicht. außerdem finde ich es komisch, daß auch mit dem orginalkernel das laden der module nicht mehr möglich ist. es gibt immer meldungen der art "unresolved symbols get_mem_state" oder so


------------------
Searching
Seek And Destroy

Backi
25.07.00, 18:43
Installier einfach das RPM mit dem Originalkernel nochmal. Dann starte neu und fang von vorn an.

Backi

25.07.00, 18:48
ich lad mir jetzt mal kernel 2.4.0-test4 herunter und probier mal den. den orginalkernel kann ich nicht installieren weil ich dafür das modul für's ISO dateisystem brauche oder das für vfat.
was hat das eigentlich mit dem initrd auf sich? hab ich bei suse, caldera, golinux nix mit zu tun gehabt.


------------------
Searching
Seek And Destroy

Backi
25.07.00, 19:55
Das ist dafür da, Module zu laden, bevor das root-fs gemountet wird. Sinnvoll immer dann, wenn man zum Mounten des root-fs irgendein Modul braucht (z.B. modularisierter SCSI-Kernel oder ext2 als Modul)

Backi

P.S. 2.4.0-test4 dürfte mehr als doppelt so groß sein wie der Redhat-Kernel http://www.linuxforen.de/ubb/wink.gif, ich mein ja bloß wegen Downloadzeit und so...


[Dieser Beitrag wurde von Backi am 25. Juli 2000 editiert.]

blackbird
25.07.00, 22:07
hi!

hier sind ja anscheinend mal ein paar modul-spezialisten zusammengekommen http://www.linuxforen.de/ubb/wink.gif bislang dachte ich immer das bei der meldung "unresolved symbols" irgendwelche abhängigkeiten nicht erfüllt sind.. wenn das so ist, hab ich dann eine chance rauszubekommen welche das wären? ist mir beim kompilieren hin und wieder vorgekommen. hat mich zwar noch nie gestört weils meistens keine wichtigen module waren, aber trotzdem würds mich mal intressieren was es damit auf sich hat.

grüse&vielen dank

blackbird

25.07.00, 23:15
Hi
immer die mit bz2 die sind kleiner

26.07.00, 10:20
blackbird:
ich hab auch gedacht das hat was mit abhängigkeiten zu tun, aber bei mir wird kein einziges modul mehr geladen!
OS/2:
na klar bz2
Backi:
beim stöbern in den Foren bleibt viel Bandbreite übrig und bei einem guten mirror krieg ich mit modem sogar 5 KB/s.
PS: der kernel hat 17MB

servus


------------------
Searching
Seek And Destroy

26.07.00, 17:52
blackbird:

mit depmod kann man sich alle Abhängigkeiten anschauen, mit einem Parameter, den ich natürlich wieder vergessen habe, ist es sogar möglich auszugeben, welche Funktionen fehlen. Wenns was bringen würde.

Nebenbei habe ich auf nem RedHat 6.2 - System einen Kernel - Patch f. ein User - IP - Accouting - System installiert. Nachher hat er auch mit seinen "unresolved symbols" herumgeballert.

Gibts wirklich niemanden, der das klären könnte ?

Gruß
- Thomas

26.07.00, 20:21
hab das problem jetzt gelöst, indem ich neu installiert habe und dann gleich kernel 2.4.0-test4 aufgespielt hab. allerdings hab ich jetzt ein neues problem (siehe neuer beitrag)


------------------
Searching
Seek And Destroy

Backi
28.07.00, 15:21
Hi!
Nach so vielen Nachfragen habe ich mich selbst etwas schlauer gelesen und wollte hier noch mal eine etwas genauere Erklärung zu den "unresolved symbols" geben:

Beim kompilieren eines Programms werden vom Compiler für jede Variable / Funktion Symbole erzeugt. Diese Symbole dienen dem Linker dazu, festzustellen, an welchen Stellen z.B. externe Funktionen aufgerufen werden. Diese Stellen bindet der Linker bei shared Libraries dann an den Laufzeit-Linker, der die benötigten Libraries zur Programmlaufzeit linkt. Bei statisch gelinkten Bibliotheken werden die benötigten Funktionen an diesen Stellen eingefügt.

Der Linux-Kernel stellt jetzt einen Sonderfall dar. Es handelt sich im Prinzip um ein dynamisch gelinktes Programm, aber er benutzt nicht den Standard-Linker, um "Bibliotheken" (Module) zu Linken, sondern benutzt eigene Tools, die die Objektdateien direkt einbinden. Die modutils benutzen die vom Compiler erzeugten Symbole, um das richtige Modul an die richtige Stelle zu laden.

Im Kernel sind also für alle bei der Kernelkonfiguration ausgewählten Module diese Symbole enthalten. Die Module wiederum enthalten entsprechende Symbole.
Beim Systemstart wird normalerweise ein Programm namens depmod ausgeführt, welches die Abhängigkeiten zwischen einzelnen Modulen anhand der Symbole prüft. Depmod überprüft, ob jedes Symbol in Kernel oder Modul ein Gegenstück besitzt und stellt damit fest, ob vor dem Laden des Moduls nicht evtl. noch ein anderes geladen werden muß.

Für jedes externe Symbol im Kernel muß ein Modul existieren, daß das entsprechende Symbol beinhaltet.
Für jedes externe Symbol in den Modulen muß ein entsprechendes Symbol im Kernel oder in einem anderen Modul vorhanden sein (da Module ja voneinander abhängig sein können, s.o.).

Wenn ich also dem Kernel ein Modul wegnehme (es lösche), dann wird depmod mich mit unresoled-symbol-Meldungen zuwerfen, da im Kernel Symbole definiert sind, die für die kein Modul existiert.
Wenn ich ein Modul von einem anderen Kernel, das im aktuellen Kernel nicht vorgesehen ist, in das Modulverzeichnis meines aktuellen Kernels kopiere, dann meckert depmod ebenfalls.

Und wenn ich mir den Sourcecode des original-RedHat-Kernels neu kompiliere, vorher aber noch alle möglichen Module abwähle, dann findet depmod haufenweise Symbole in den Modulen im Modulverzeichnis, die im Kernel nicht vorhanden sind. Abhilfe schafft hier, wie schon oben beschrieben eine Änderung der Versionsnummer des Kernels. Wenn ich dann trotzdem noch mit unresolved-symbol Meldungen vollgemüllt werde, dann habe ich entweder vergessen, eine neue initrd zu erstellen, oder das Kompilieren der Module hat nicht 100%ig geklappt.

Ich hoffe, das Problem ist jetzt etwas klarer.

Backi

29.07.00, 23:09
hallo zusammen,
will mich nicht groß einmischen, weil ich eigendlich kaum ahnung habe. Allerding habe ich letztens was davon gelesen, daß man beim kernel kompilieren auch eine option darauf hat, seine module versionsunabhängig zu kompilieren, weil man sonst bei jedem neuen kernel eigendlich auch die module neu komp- und installieren muß, jedenfalls bei meinem suse6.3
hoffe, das war jetzt nicht zu banal...
ciao

11.11.00, 07:26
Hallo allerseits!

Ich stecke ganz tief in den unresolved Symbols -- Bis zum Hals http://www.linuxforen.de/ubb/frown.gif

Schön und gut:
Ich habe ein Debian 2.2 mit Kernel 2.2.17 installiert und wollte meinen Kernel neumachen. Dazu habe ich die Originalquellen besorgt, alle verfügbaren Anleitungen gelesen und anschließend alles brav gemacht.
Aber ich bekomme immer noch diese tollen Meldungen und kann kein Modul installieren; bis auf die Netzwerkkarte, die geht glücklicherweise.
Unresolved Symbols gibt es, wenn ein Modul, das gerade ins System gelinkt werden soll, Symbole benutzen will, die es weder selbst beinhaltet (Also eigene Variablen, Pointer, Proceduren etc.) noch der Kernel sie exportiert.
cat /proc/ksysms gibt mir auch nur relativ wenig aus, auf meinem Server hingegen, wo der Kernel original ist, gibt es kein Problem, alle für die Module benötigten Symbole sind da.

Was zur Hölle sind folgende Dateien:
/boot/System.map
Da stehen alle Symbole fein säuberlich drin
Brauche ich das vielleicht?

/boot/map
???

Wer mir helfen kann, möge sich bitte melden, ich weiß einfach nicht weiter.
Danke.

18.11.00, 20:00
/usr/src/linux/System.map nach /System.map bzw. /boot/System.map kopieren (wenn es eine eigene boot - Partition gibt)

make bzlilo macht das automatisch bzw. muss man es bei make bzImage selber kopieren.

Laut Suse-Handbuch (5.3):
Die Datei System.map enthält die Kernelsymbole, die die Kernelmodule benötigen, um Kernelfunktionen korrekt aufrufen zu können. Die DAtei ist abhängig vom aktuellen Kernel.