Kernel Module: unresolved symbols make modules_install
Hallo Leute, Im Zuge einer VPN Installation (ipsec) mußte ich den SUSE Kernel 2.4.21.199 neu kompilieren. Ich bin nach Thomas Hertweck (http://www.thomashertweck.de/kernel24.html) HOWTO vorgegangen. Nun sehe ich nach erfolgereichem Compile-Vorgang für den Kernel und seinen Modulen bei #> make modules_install folgenden Ausgang. .... find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.21-199-"default"; fi depmod: *** Unresolved symbols in /lib/modules/2.4.21-199-default/pcmcia/hostap_cs.o depmod: hostap_netif_wake_queues_R4636e4e9 depmod: hostap_80211_get_hdrlen_R6903f16c depmod: hostap_remove_proc_R59cbc1ab depmod: hostap_80211_rx_R73fcd0db depmod: hostap_get_porttype_R5da10a5c depmod: hostap_set_hostapd_R41542087 depmod: hostap_setup_dev_Refa9e64b depmod: hostap_info_init_R9be47c83 depmod: hostap_free_data_R90c31726 depmod: hostap_set_string_Re0f3d560 depmod: hostap_handle_sta_release_R27df6133 depmod: hostap_get_stats_R6cca4d37 depmod: hostap_handle_sta_tx_exc_R8564c8e2 depmod: hostap_set_roaming_R3571a53e depmod: hostap_check_sta_fw_version_R3fd2f735 depmod: hostap_set_antsel_R69f6f68d depmod: hostap_set_word_Rf5875ea1 depmod: hostap_init_data_R64e42bbc depmod: hostap_set_multicast_list_queue_Rc089a779 depmod: hostap_netif_stop_queues_Rc1460907 depmod: hostap_init_proc_R0eecb7e1 depmod: hostap_dump_rx_header_R27a069d6 depmod: hostap_set_encryption_R5cb16fef depmod: hostap_dump_tx_header_R3abcbf80 depmod: hostap_handle_sta_tx_R8c57fa50 depmod: hostap_info_process_R77fa3e53 depmod: *** Unresolved symbols in /lib/modules/2.4.21-199-default/pcmcia-external/prism2_cs.o depmod: p80211netdev_hwremoved depmod: register_wlandev depmod: p80211netdev_rx depmod: unregister_wlandev depmod: wlan_setup depmod: wlan_unsetup linuxserver:/usr/src/linux # Unschlüssig, ob das nun ein Fehler ist, habe ich mittels linuxserver:/usr/src/linux # echo $? 0 versucht, den letzten Fehlercode herauszubekommen. 0 scheint okay zu sein, aber ich wollte nur mal sichergehen... Bin dankbar für jede Hilfe ;-) Grüssse Dennis
Dennis Leist wrote:
Was mir sofort auffaellt: 2.4.21-199-default (das scheint "uname -r" bei Deinem selbstcompilierten Kernel zu liefern; stimmt das?) entpricht genau dem SuSE Standardkernel. Wenn man einen eigenen Kernel bastelt, dann sollte man auf alle Faelle entweder ueber die Konfiguration (das geht nur bei SuSE) oder im Kernel-Makefile (das geht immer) Anpassungen vornehmen, dass sich der neue Kernel in ein eigenes Module-Verzeichnis installiert, d.h. man muss eine EXTRAVERSION setzen. Sonst kann es hier zu Konflikten kommen, wenn die Konfigurationen (insbesondere im Hinblick auf "fest in den Kernel compiliert" oder "als Modul realisiert") unterschiedlich sind.
Die zwei Module prism2_cs.o und hostap_cs.o weisen sog. "unresolved symbols" auf, d.h. es tauchen dort Symbole auf, die nicht aufgeloest werden koennen. Vereinfacht ausgedrueckt: das Modul verwendet externe Resourcen, findet diese aber nicht. Folge: die zwei Module koennen nicht geladen, also auch nicht verwendet werden. Ursache: moeglicherweise eine fehlerhafte Kernelkonfiguration, oder auch Bugs beim Kernel, oder eine fehlerhafte Installation (mehrere Versuche, Module aus unterschiedlichen Kernelkonfigurationen in ein und dasselbe Verzeichnis zu installieren; siehe dazu auch Kommentar zu Beginn dieser Mail), usw., da kommt einiges in Frage. Loesung: Wenn Du diese Module nicht brauchst, kannst Du die Meldungen ignorieren. Wenn Du die Module definitiv brauchst, dann musst Du herausfinden, was genau das Problem verursacht, was evtl. fehlt bzw. was die verwendeten Symbole bereit stellt, und dann den Fehler korrigieren. CU, Th.
Dennis Leist wrote:
Build Options -> Configuration Name und Build Options -> Release Number Daraus wird dann <version>-"release number"-"configuration name", also z.B. eben 2.4.21-199-default (siehe oben, SuSE Default Kernel) oder bei eigenen Angaben z.B. auch 2.4.21-0-dennis oder so. Module wuerde dann nach /lib/modules/2.4.21-0-dennis installiert werden und damit nicht mehr ins gleiche Verzeichnis wie die Module des SuSE Default Kernels. Dieses Feature (d.h. das Anpassen der EXTRAVERSION ueber die Kernel Konfiguration) gibt es nur bei SuSE Kerneln und erst seit einigen Releases. CU, Th.
Wow, Merci. Habe ich Deinem ausgedruckten HOWTO gleich beigelgt. CU Dennis
Thomas Hertweck wrote:
Was mir sofort auffaellt: 2.4.21-199-default (das scheint "uname -r" bei Deinem selbstcompilierten Kernel zu liefern; stimmt das?)
Das ist der aktuelle SuSE-Kernel vom YOU.
EXTRAVERSION setzen. Sonst kann es hier zu Konflikten kommen, wenn
Suse produziert so einen Unsinn selbst, beim YOU wird, wenn ein neuer Kernel vorliegt, der neue Kernel sowie das neue Modul-Verzeichnis installiert. Blöderweise deinstallieren sie das Modulverzeichnis des alten (=laufenden) Kernels. Korrekterweise sollte beim Starten des neuen Kernels dieser erst das alte Modulverzeichnis löschen (wenn überhaupt gewünscht). Damit könnte man noch tagelang mit dem laufenden System weiterarbeiten. Bernd
Bernd Laengerich wrote:
Was fuer einen Sinn haette das? Wenn es einen neuen Kernel von SuSE gibt, dann nicht ohne Grund - es liegen dann vermutlich etliche Bugfixes und/oder Securityfixes vor und der neue Kernel sollte moeglichst bald seinen Dienst versehen. Das kann er aber nur, wenn er auch gebootet wird. Also macht man das Kernel Update genau dann, wenn man Zeit hat und das System rebooten kann und rebooten tut man dann moeglichst auch sogleich. Weitere Zeit mit einem buggy Kernel zu verbringen muss ja nicht sein. Wenn man zwar YOU laufen lassen moechte, aber keine Zeit fuer einen Reboot hat, dann kann man ja explizit das Kernel Update abwaehlen und zu einem spaeteren Zeitpunkt durchfuehren. Zu Deinem Beispiel: Wenn Du also noch weiter arbeitern moechtest, dann mache schlicht kein Kernel Update zu diesem Zeitpunkt - es bringt Dir ja eh nichts, solange Du den neuen Kernel nicht bootest. Dann kannst Du es zu diesem Zeitpunkt auch sparen. Und dann bleibt auch Dein vorhandenes Moduleverzeichnis bestehen. Das alte Moduleverzeichnis auch nach dem Reboot aufzuheben haette keinen Sinn, da der dazu passende Kernel nicht mehr existiert - es wurde ja ein Update gemacht, d.h. der alte Kernel ersetzt; YOU installiert den neuen Kernel nicht parallel zum alten - wenn Dein Vorschlag Sinn machen sollte, muesste YOU ganz anders vorgehen. Als erfahrenerer Linux-User wuerde ich Kernel Updates (u.a. deswegen) auch nicht durch YOU durchfuehren lassen, sondern entsprechende neue Kernel selbst von Hand einspielen - in diesem Falle waere dann z.B. auch ein paralleles Installieren zu anderen Kerneln kein Problem. Gruesse, Thomson
participants (3)
-
Bernd Laengerich -
Dennis Leist -
Thomas Hertweck