Nach Kompilierung: Invalid module format

[Frittenbude]

Hallo zusammen,

ich habe mein System softwareseitig auf einen neueren Stand gebracht und wollte nun Asterisk mit bristuff inkl. Florz-Patch neu kompilieren. Das Kompilieren selbst läuft scheinbar auch durch.
Aber die dadurch erstellten Treiber lassen sich merkwürdigerweise nicht laden.

Ich erhalte folgende Fehlermeldung:

[root@gateway extra]# insmod ./zaptel.ko
insmod: error inserting './zaptel.ko': -1 Invalid module format

Hier noch ein paar ergänzende Infos:

[root@gateway extra]# file zaptel.ko
zaptel.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

[root@gateway extra]# pwd
/lib/modules/2.6.9-27.cc/extra

[root@gateway extra]# uname -r
2.6.9-27.cc

[root@gateway extra]# rpm -qa |grep kernel
kernel-2.6.9-27.cc
kernel-2.6.9-19.cc
kernel-devel-2.6.9-19.cc
kernel-devel-2.6.9-27.cc

[root@gateway src]# ls -lah |grep linux
lrwxrwxrwx 1 root root 34 13. Feb 12:55 linux -> /usr/src/kernels/2.6.9-27.cc-i586/
lrwxrwxrwx 1 root root 34 13. Feb 12:55 linux-2.6 -> /usr/src/kernels/2.6.9-27.cc-i586/

[root@gateway 2.6.9-27.cc-i586]# pwd
/usr/src/kernels/2.6.9-27.cc-i586
[root@gateway 2.6.9-27.cc-i586]# ls
arch fs ipc Makefile net sound
crypto include kernel mm scripts usr
drivers init lib Module.symvers security

Wie man sehen kann, sollte eigentlich alles richtig verlinkt sein (Kernel-Sources).

Hat jemand eine Idee, warum die Module ein falsches Format haben?

Gruß,
Frittenbude

 

[kombjuder]

Hast du 'ne Suse laufen?

Die haben zum Teil andere Pfade. Du kompilierst die neuen Treiber in die für Suse falschen Verzeichnisse und Suse findet dann nur die alten und benutzt die.

 

[britzelfix]

@Frittenbude

Das lag bei mir letztens am neuem gcc.
Nimm statt 4.X den gcc 3.3

Gruß
britzelfix

 

[Frittenbude]

Hallo,

SuSE benutze ich nicht, sondern ein auf Redhat Enterprise 3 basierendes ClarkConnect 3.2.
Kernel ist ein 2.6.9er.

@ kombjuder:
Trifft die Sache bezüglich SuSE auch auf Redhat zu? Ist Dir da etwas bekannt?

@ britzelfix:
Mein GCC ist ein 3.3er.

[root@gateway src]# rpm -qa |grep gcc
libgcc-3.3.3-7
gcc-g77-3.3.3-7
gcc-objc-3.3.3-7
gcc-3.3.3-7
gcc-c++-3.3.3-7
gcc-java-3.3.3-7

Ergänzend dazu muss ich aber noch sagen, dass einige Dependencies eventuell nicht richtig erfüllt werden, bzw. Libraries nicht die richtige Version haben. Da mir gcc-c++ fehlte, habe ich versucht alle kompilierungsbezogenen Tools zu deinstallieren und mittels apt-get automatisch installieren zu lassen. Dabei gab's dann aber ständig Abhängigkeitsprobleme, wodurch ich wieder alles von Hand installieren wollte.
Dabei habe ich bei einigen Developer-Tools nicht immer die exakt gleiche Version zum Hauptprogramm gefunden.
Hier ein Beispiel:

glibc-2.3.5-10
glibc-devel-2.3.3-27.1

Ich hoffe, dass ich mir mein System nicht zerschossen habe. ;(

Naja, jetzt versuche ich jedenfalls gerade den neuesten Kernel (2.6.15.4) zu kompilieren und anschließend zu booten. Danach werde ich bristuff und mISDN mal neu kompilieren.

Im Moment ist es jedenfalls so, dass keine von mir kompilierten Treiber mehr funktionieren. Weder zaptel und zaphfc noch mISDN.

Gruß,
Frittenbude

 

[kombjuder]

H

@ kombjuder:
Trifft die Sache bezüglich SuSE auch auf Redhat zu? Ist Dir da etwas bekannt?

Nein, bisher kenne ich das nur von Suse. Alle anderen Distributionen kochen normalerweise kein eigenes Süppchen.

 

[Frittenbude]

Hi,

ich habe gestern mal einen Kernel (2.6.15.4) kompiliert. Anschließend funktionierte auch das Kompilieren von zaphfc und auch das Laden des Treibers.

Blöderweise kann ich den Kernel aber nicht einsetzen, da das Routing nicht mehr funktioniert, seitdem ich diesen Kernel verwende. Keine Ahnung warum.
Der Rechner (Gateway) selbst hat noch eine Internetverbindung und er ist auch von sämtlichen internen Clients erreichbar. Wie gesagt, nur das Routing klappt nicht.

Weiß zufällig jemand, ob man dafür eine spezielle Funktion im Kernel aktivieren muss, die standardmäßig nicht aktiviert ist?

Gruß,
Frittenbude

 

[lo4dro]

Die zaptel und zaphfc sind kernel module, daher müssem die mit dem selben Kompiler gebaut werden wie der gerade laufende Kernel.

@Frittenbude
oft kann man unter /proc/config[.gz] die aktuelle laufene Konfig auslesen.

 

[britzelfix]

@lo4dro

Das ist richtig. Alternativ geht auch cat /proc/version
Allerdings habe ich da so meine Problemchen mit
gcc 4.2, den Kernel habe ich noch nicht zum laufen gebracht.

Gruß
britzelfix

 

[Frittenbude]

Hi,

also eigentlich habe dürfte ich die passenden Kernel-Sources zu meinem Kernel haben. Ich habe auch schon andere Kernelpakete meiner Distribution installiert und dazu auch die passenden Kernel-Sources benutzt.

Die Treiber klappen aber nach einer anschließenden Kompilierung einfach nicht mehr.

Wenn ich, wie gesagt, einen Kernel selbst neu kompiliere, funktioniert eine anschließende Treiberkompilierung tadellos. Dabei geht aber das Routing hops.

Ich habe jetzt schon alles Mögliche ausprobiert, aber ich komme nicht weiter.

"cat /proc/version" gibt mir übrigens folgendes aus:

Linux version 2.6.9-19.cc ([email protected]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)) #1 Fri Jul 8 16:43:18 EDT 2005

Eine "/proc/config*" gibt es bei mir scheinbar nicht. Aber wenn das die Kernel-.config sein sollte, so habe ich sie ja in meinem Kernel-Source-Verzeichnis.

Notfalls muss ich halt die Kiste komplett neu aufsetzen, was ich eigentlich ja vermeiden wollte.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Ok, /proc/config.gz ist nicht da.
Dann such mal den Kernel unter /boot, bzw. wenn Du grub
verwendest dann in /boot/grup/menu.lst, bei
lilo die /etc/lilo.cfg

Die "config" "System.map" und "vmlinuz" befindet sich
bei mir im /boot .

Wenn Du die "config" gefunden hast, dann speicher sie einfach in das
/usr/kernel/linux o.ä. als .config (führendes "." nicht vergessen!)
ab. Danach den Kernel neu compilieren und installieren.

Gruß
britzelfix

 

[Frittenbude]

Danke für die Antwort, britzelfix.

Die Configs liegen tatsächlich in "/boot".

Also wenn ich die entsprechende Config-Datei in den neu zu kompilierenden Kernel-Pfad als .config ablege, muss ich dann "make oldconfig" ausführen?
Eigentlich nicht, oder?

Also einfach nur kompilieren lassen, sollte reichen, richtig?

EDIT:
So, ich habe das gerade mal so durchgeführt. Nach Start von "make" kommen folgende Abfragen:

Appletalk protocol support (ATALK) [M/n/y/?] m
Appletalk interfaces support (DEV_APPLETALK) [Y/n/?] y
Apple/Farallon LocalTalk PC support (LTPC) [N/m/y/?] n
COPS LocalTalk PC support (COPS) [N/m/y/?] n
Appletalk-IP driver support (IPDDP) [N/m/?] n
CCITT X.25 Packet Layer (EXPERIMENTAL) (X25) [N/m/y/?] n
LAPB Data Link Driver (EXPERIMENTAL) (LAPB) [N/m/y/?] n
Frame Diverter (EXPERIMENTAL) (NET_DIVERT) [Y/n/?] y
Acorn Econet/AUN protocols (EXPERIMENTAL) (ECONET) [N/m/y/?] n
WAN router (WAN_ROUTER) [M/n/y/?] m
Forwarding between high speed interfaces (NET_HW_FLOWCONTROL) [N/y/?] (NEW)

Er ging einfach alle Abfragen automatisch durch, bis er zu "Forwarding between ..." angekommen ist. Genau das Gleiche hatte ich schon mal. Danach kam noch eine weitere Abrage nach einem "New Kernel Stack" oder so ähnlich.
Also wenn er jetzt problemlos durchkompilieren sollte und ich den Kernel anschließend boote, wird es wohl wieder so sein, dass das Routing plötzlich nicht mehr klappt, sobald ich eine Seitenanfrage in meinem Webbrowser gemacht habe. Bisher war es grundsätzlich so, dass ein Teil der Seite noch geladen wird, doch das Routing kurz darauf zusammenbricht.

Falls es gleich wieder der Fall sein sollte, gebe ich es wohl auf und muss in den sauren Apfel beißen, um die Kiste endlich wieder vollständig lauffähig zu bekommen.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Grmpf. Ich denke Du hast schon ein Kernel selbst kompiliert?
Es gibt dazu x-Howtos.

Du hast schon die config, daher kein oldconfig menuconfig oder xconfig.
Ich mache meistens folgendes:
make clean
make bzImage modules
make modules_install
make install INSTALL_ROOT=/boot

wenn Du grub hast, dann die Abfrage wg. lilo verneinen und
anschließend grub-install /dev/hda o.ä.
Man muß sich auch vorher vergewissern, daß in lilo/grub configs
ein neuer Eintrag mit einem neuem Kernel vorhanden ist.
Dann booten.

Gruß
britzelfix

 

[Frittenbude]

Hi,

generell ist mir ja bekannt, wie ich beim Kompilieren vorgehe. Ich habe in der Regel bisher den Kernel komplett selbst konfiguriert und daher keine alten Configs als Basis genommen. War mir daher nicht sicher, ob ich "make "oldconfig" ausführen muss.

Wie ich schon sagte, der Kernel bootet nach dem Kompilieren und Einrichten problemlos. Nur das Routing bricht nach ein wenig Traffic einfach weg; egal was ich im Kernel einstelle.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Nun, das Routing Problem wird dann nicht auftreten,
wenn Du so vorgehst, wie ich es beschrieben habe,
denn dann wirst Du einen identisch konfigurierten Kernel haben,
der mit einem anderem Compiler compiliert wurde.

Was Du dann anschließend veränderst, ist Deine Sache.

Alternativ dazu kannst Du den 3.4er gcc benutzen, der
wird sich doch einfacher finden lassen.

Gruß
britzelfix

 

[Frittenbude]

OK, danke britzelfix.

Ich werde es nach abgeschlossener Kompilierung testen.

Meine derzeitige GCC-Version ist übrigens 3.4.3.

Danke nochmals für Deine Mühe.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Keine Ursache.

Noch als kleiner Tip: nach dem "insmod" kann man
sich die Debug-Ausgaben mit "dmesg" anschauen.

Gruß
britzelfix

 

[Frittenbude]

Also, ich den GCC 3.3.x nach Deinem Hinweis auf 3.4.x aktualisiert. Seitdem klappt das Kompilieren von Treibern wieder.

Nach wie vor funktioniert aber das Routing nicht, wenn ich einen Kernel selbst kompiliere. Auch dann nicht, wenn ich eine alte .config als Basis nehme.

Das ist zwar schade, da ich den Kernel nicht an meine Hardware napassen kann; aber Hauptsache Treiber lassen sich wieder einwandfrei kompilieren.

Damit hat sich das Thema "Invalid module format" erledigt.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Danke. Was ist das für ein Routing-Problem?

Gruß
britzelfix

 

[Frittenbude]

Also sobald ich einen selbst kompilierten Treiber boote, routet der Server nicht mehr. Der Server hat aber eine Internetverbindung und er ist auch von interner Seite vollständig erreichbar.
Dass die Internetverbindung besteht, kann mittels eines ssh-Logins auf den Server testen.

Ich habe es schon mit dem neuesten 2.6.15.4er Kernel getestet. Und um sicher zu gehen, dass die Version nicht vielleicht einen Bug oder ähnliches hat, habe ich einmal einen 2.6.9er benutzt. Denn diese Version ist auch in einer leicht veränderten Version (2.6.9-19) in meiner Distribution integriert.

Mein letzter Test bestand dann darin, dass ich mit jedem dieser Kernel eine alte .config genutzt habe.

Bei keiner der genutzten hat das Routing überhaupt einmal funktioniert.

In log-Files (auch dmesg) ist mir nichts aufgefallen.

Ob das jetzt mit der Firewall zu tun hat oder das Routing selbst ist, weiß ich absolut überhaupt nicht.

Gruß,
Frittenbude

 

[britzelfix]

@Frittenbude

Das klingt so, als ob NAT nicht eingeschaltet währe.
Den .config Trick kann man nur auf gleiche Kernel anwenden.
Wenn man es mit unterschiedlichen macht, dann sollte man
alles noch mal duchchecken. Am besten Du öffnest 2 Terminals
nebeneinander und vergleichst die Einstellungen Punkt für Punkt.
Check mal die Einstellungen für Network packet filtering.

Gruß
britzelfix