nvidia-error : most wrong kernel source files
hallo ich habe schon mehrfach erfolgreich nvidia unter einem selbst gebauten Kernel installiert. Jetzt habe ich die kernel-source-2.6.5-7.75-default als 2.6.5-7.75-2 selbst kompiliert und kann auch damit booten: ro999:~ # uname -r 2.6.5-7.75-2 ro999:~ # Nur diesmal kriege ich nvidia nicht zum Laufen. Die Fehlermeldungen laut nvidia-installer.log lauten: - - - - - - - - - - s n i p p [ . . . .] -> Kernel module linked successfully. ERROR: Unable to load the kernel module 'nvidia.ko'. This is most likely because the kernel module was built using the wrong kernel source files. Please make sure you have installed the kernel source files for your kernel; [ . . . ] -> Kernel module load error: insmod: error inserting './usr/src/nv/nvidia.ko': -1 Invalid module format ERROR: Installation has failed. [ . . . .] - - - - - - - - -- s n i p p Auch Dazuko meldet beim Installieren: "[ . . .]Please make sure that you compile Dazuko using the SAME source code as your kernel. [ . . .]" Dasselbe passierte mir zuletzt mit Kernel 2.6.52-default, erledigte sich aber, als ich eine eindeutige Bezeichnung vergeben hatte (2.6.4-52-3). Was ist anders bei den kernel-source-2.6.5-7.75-default vom SuSE-ftp-Server? Vielleicht mache ich ja trotz allem noch grundsätzliche Fehler, obwohl ich das "Linux-Kernel-HOWTO von Thomas Hertweck schon 'zig Mal studiert habe? Hier also zum Mitdenken: (ich weiß, nicht alles ist schön, was ich gemacht habe, aber stört das die Kernels-Source und wenn ja, was soll ich tun?) 1) Kernel-Source-2.6.5-7.75.i586.rpm installiert mit rpm -ivh --force --nodeps *.rpm Installation unter /usr/src erfolgreich Wegen selbst produziertem Ärger habe ich dann die Kernel-Source 2.6.5-7.75 (-default) verschoben (als Ersatzlösung für ein rpm -e (bzw. Löschen mit yast, weil zwar unter /usr/src eine parallele Installation erfolgt , in yast-Software aber die Installation als Update behandelt wird. Und an ein Löschen aller Sourcen mit anschließender Neuinstallation (wie gehabt) habe ich mich nicht ran getraut. Anschließend habe ich die Kernel-Sourcen (2.6.5-7.75) wieder wie oben installiert. Keine erkennbaren Probleme. 2) Als Vorbereitung zum Kompilieren habe ich dann ausgeführt: cp /usr/src/linux-2.6.5-7.75 /usr/src/linux-2.6.5-7.75-2 Anschließend wurde /ur/src/linux gelöscht und für /usr/src/ linux-2.6.5-7.75-2 als Link neu angelegt. Anschließend habe ich "make mrproper" ausgeführt. 3) Statt "make cloneconfig bzw. make oldconfig habe ich eine eigene .config-Datei nach /usr/src/linux kopiert, geöffnet, um darin Build Options - CONFIG_ CFGNAME="default" zu ändern in ="2" und abschließend gespeichert. Alsdann habe ich ausgeführt: "make prepare" Diese Handhabung habe ich gewählt, weil nach meinen Feststellungen z.B. bei einem "make cloneconfig && make prepare" die Angaben unter /usr/src/linux-2.6.5-7.75-2/include/linux/version.h nicht auf die neue Kernelbezeichnung "2" statt vorher "default" geändert wird. Als Folge davon wurde bei mir danach nicht der neue Kernel, sondern der alte (laut version.h) gebootet. Nun, was danach kommt, ist wohl normal: make xconfig - make clean - make bzImage usw. Achja, die /usr/src/linux-2.6.5-7.75-obj habe ich genauso behandelt wie die sourcen selbst (braucht man die *-obj wirklich noch nach einem Übersetzen?) Es ist ja dann auch der neue Kernel installiert und gebootet worden. Nur Nvidia (und Dazuko) stören sich an den Kernel-Sourcen. Ich meine, sie sind eindeutig, oder? Liegt es womöglich an dem *.rpm von SuSE? Sollte ich ein *.tar.gz downloaden? (Dann hätte ich keine Probleme mit der RPM-Datenbank (Yast) Noch zum Schluß: Installationsvarianten für nvidia haben keinen Erfolg gebracht (bei dazuko gibt es keine Alternative). Für jede Hilfe dankbar Gruß Rolf
Rolf Hoff wrote:
[...] ro999:~ # uname -r 2.6.5-7.75-2 ro999:~ # [...] Nur diesmal kriege ich nvidia nicht zum Laufen. Die Fehlermeldungen laut nvidia-installer.log lauten: [...]
Auf was verweist der Link /usr/src/linux? Auf was verweist der Link /lib/modules/`uname -r`/build? Was liefert ein "grep CONFIG_REGPARM .config", wenn Du im Verzeichnis mit den zugehoerigen Kernelquellen bist? Was liefert ein "cat /lib/modules/`uname -r`/build/include/linux/version.h"? (Bitte die Anweisungen verstehen und sinnvoll ausfuehren, falls Du sie anpassen musst - sollte hoffentlich nicht noetig sein).
[...] 2) Als Vorbereitung zum Kompilieren habe ich dann ausgeführt: cp /usr/src/linux-2.6.5-7.75 /usr/src/linux-2.6.5-7.75-2
Das Kommando stimmt so hoffentlich nicht, sondern Du hast das rekursiv durchgefuehrt, oder? Oder Du hast ein "mv" gemacht, um es einfach umzubenennen.
Anschließend wurde /ur/src/linux gelöscht und für /usr/src/ linux-2.6.5-7.75-2 als Link neu angelegt. Anschließend habe ich "make mrproper" ausgeführt.
3) Statt "make cloneconfig bzw. make oldconfig habe ich eine eigene .config-Datei nach /usr/src/linux kopiert, geöffnet, um darin Build Options - CONFIG_ CFGNAME="default" zu ändern in ="2" und abschließend gespeichert. Alsdann habe ich ausgeführt: "make prepare"
Diese Handhabung habe ich gewählt, weil nach meinen Feststellungen z.B. bei einem "make cloneconfig && make prepare" die Angaben unter /usr/src/linux-2.6.5-7.75-2/include/linux/version.h nicht auf die neue Kernelbezeichnung "2" statt vorher "default" geändert wird. Als Folge davon wurde bei mir danach nicht der neue Kernel, sondern der alte (laut version.h) gebootet.
Ein "make cloneconfig" klont _exakt_ die Konfiguration des laufenden Kernels, _inklusive_ einer evtl. vorhandenen CONFIG_CFGNAME und CONFIG_RELEASE. Willst Du eine eigene Release-Nummer, so musst Du die natuerlich aendern (beliebiger Editor oder "make menuconfig" bzw. make xconfig"). Danach ein "make prepare", und dann ist die Datei version.h auch korrekt. Wenn Du schlicht ein "make cloneconfig && make prepare" machst, warum sollte sich dann spontan aus freien Stuecken eine Variable von "default" auf "2" aendern? Das kann ja nicht sein. Wie gesagt: es wird _geklont_, nichts geaendert dabei. Gruesse, Th.
Thomas Hertweck schrieb:
Rolf Hoff wrote:
[...] ro999:~ # uname -r 2.6.5-7.75-2 ro999:~ #
[...] Nur diesmal kriege ich nvidia nicht zum Laufen. Die Fehlermeldungen laut nvidia-installer.log lauten: [...]
Auf was verweist der Link /usr/src/linux?
ro999:~ # ls -l /usr/src/linux lrwxrwxrwx 1 root root 27 2004-06-28 16:58 /usr/src/linux -> /usr/src/linux-2.6.5-7.75-2 ro999:~ #
Auf was verweist der Link /lib/modules/`uname -r`/build?
ro999:~ # ls -l /lib/modules/2.6.5-7.75-2/build lrwxrwxrwx 1 root root 27 2004-06-28 17:49 /lib/modules/2.6.5-7.75-2/build -> /usr/src/linux-2.6.5-7.75-2 ro999:~ #
Was liefert ein "grep CONFIG_REGPARM .config", wenn Du im Verzeichnis mit den zugehoerigen Kernelquellen bist?
ro999:/usr/src/linux-2.6.5-7.75-2 # grep CONFIG_REGPARM .config # CONFIG_REGPARM is not set ro999:/usr/src/linux-2.6.5-7.75-2 #
Was liefert ein "cat /lib/modules/`uname -r`/build/include/linux/version.h"? (Bitte die Anweisungen verstehen und sinnvoll ausfuehren, falls Du sie anpassen musst - sollte hoffentlich nicht noetig sein).
ro999:~ # cat /lib/modules/2.6.5-7.75-2/build/include/linux/version.h #define UTS_RELEASE "2.6.5-7.75-default" #define LINUX_VERSION_CODE 132613 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) ro999:~ #
[...] 2) Als Vorbereitung zum Kompilieren habe ich dann ausgeführt: cp /usr/src/linux-2.6.5-7.75 /usr/src/linux-2.6.5-7.75-2
Das Kommando stimmt so hoffentlich nicht, sondern Du hast das rekursiv durchgefuehrt, oder? Oder Du hast ein "mv" gemacht, um es einfach umzubenennen.
Nein, kein mv Ich habe im Konqueror unter /usr/src einfach mit der Maus das Verzeichnis linux-2.6.5-7.75 auf /usr/src gezogen und dann kopieren gewählt, dabei wurde dann die Version "-2" mitgegeben. Was ist beim Verschieben anders? Bei mir lief ja zunächst der Kernel "default" bis ich dann "-1" bzw "-2" kompiliert und installiert habe. Jetzt habe ich alle drei nebeneinander. Gruß Rolf
Rolf Hoff wrote:
["uname -r" liefert "2.6.5-7.75-2"] ["/usr/src/linux" verweist auf "/usr/src/linux-2.6.5-7.75-2"] ["/lib/modules/2.6.5-7.75-2/build" verweist auf "/usr/src/linux-2.6.5-7.75-2"] [...] ro999:~ # cat /lib/modules/2.6.5-7.75-2/build/include/linux/version.h #define UTS_RELEASE "2.6.5-7.75-default" #define LINUX_VERSION_CODE 132613 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) ro999:~ #
Die letzte Ausgabe zeigt, dass Dein Kernel-Source in /usr/src/linux-2.6.5-7.75-2 nicht fuer den laufenden Kernel konfiguriert ist, denn sonst muesste dort bei UTS_RELEASE ein "2.6.5-7.75-2" und nicht ein "2.6.5-7.75-default" stehen. Die Links sehen ansonsten korrekt aus. Was sagt ein "zcat /proc/config.gz | tail -n 8"? Hast Du wirklich bei laufendem Kernel 2.6.5-7.75-2 (!) ein "make cloneconfig && make prepare" in /usr/src/linux-2.6.5-7.75-2 ausgefuehrt? Dann muesste eigentlich die Datei version.h auch korrekt sein und nicht falsch wie bei Dir. So wie es momentan ist, verursacht es natuerlich Probleme beim Uebersetzen externer Module. Hast Du auf evtl. Fehlermeldungen geachtet?
[...] Nein, kein mv Ich habe im Konqueror unter /usr/src einfach mit der Maus das Verzeichnis linux-2.6.5-7.75 auf /usr/src gezogen und dann kopieren gewählt, dabei wurde dann die Version "-2" mitgegeben.
Was ist beim Verschieben anders?
Ich benutze kein konqueror. Bei einem normalen "cp" Befehl an der Kommandozeile mit einem Verzeichnisnamen (z.B. "cp dir1 dir2") passiert gar nichts, da muss dann naemlich die Option "-r" verwendet werden zum rekursiven Kopieren. Ein "mv dir1 dir2" hingegen wird funktionieren, allerdings unterschiedlich je nachdem, ob dir2 existiert oder nicht. So ganz blicke ich bei Deinem Installieren, Verschieben, Kopieren, usw. nicht mehr durch. Irgendwo laeuft da etwas schief, aber das ist alles reichlich unuebersichtlich. Ich habe solche Probleme wie bei Dir noch nie erlebt, obwohl ich mittlerweile im Laufe der Zeit wahrscheinlich etliche hundert Kernel erstellt habe. Kernel-Source entpacken, konfigurieren, installieren - funktioniert bei mir eigentlich immer... CU, Th.
Thomas Hertweck schrieb:
Rolf Hoff wrote:
["uname -r" liefert "2.6.5-7.75-2"] ["/usr/src/linux" verweist auf "/usr/src/linux-2.6.5-7.75-2"] ["/lib/modules/2.6.5-7.75-2/build" verweist auf "/usr/src/linux-2.6.5-7.75-2"] [...] ro999:~ # cat /lib/modules/2.6.5-7.75-2/build/include/linux/version.h #define UTS_RELEASE "2.6.5-7.75-default" #define LINUX_VERSION_CODE 132613 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) ro999:~ #
Die letzte Ausgabe zeigt, dass Dein Kernel-Source in /usr/src/linux-2.6.5-7.75-2 nicht fuer den laufenden Kernel konfiguriert ist, denn sonst muesste dort bei UTS_RELEASE ein "2.6.5-7.75-2" und nicht ein "2.6.5-7.75-default" stehen. Die Links sehen ansonsten korrekt aus. Was sagt ein "zcat /proc/config.gz | tail -n 8"?
wieselsdachsbau:~ # zcat /proc/config.gz | tail -n 8 # # Build options # CONFIG_SUSE_KERNEL=y CONFIG_CFGNAME="2" CONFIG_RELEASE="7.75" CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y wieselsdachsbau:~ #
Hast Du wirklich bei laufendem Kernel 2.6.5-7.75-2 (!) ein "make cloneconfig && make prepare" in /usr/src/linux-2.6.5-7.75-2 ausgefuehrt? Dann muesste eigentlich die Datei version.h auch korrekt sein und nicht falsch wie bei Dir. So wie es momentan ist, verursacht es natuerlich Probleme beim Uebersetzen externer Module. Hast Du auf evtl. Fehlermeldungen geachtet?
Wie am 28.06.04 berichtet: (auszugsweise Wiedergabe) - - - - - s n i p p 3) Statt "make cloneconfig bzw. make oldconfig habe ich eine eigene .config-Datei nach /usr/src/linux kopiert, geöffnet, um darin Build Options - CONFIG_ CFGNAME="default" zu ändern in ="2" und abschließend gespeichert. Alsdann habe ich ausgeführt: "make prepare" - - - - - s n i p p Nach dem "make prepare" lautete version.h auch 2.6.5-7.75-2 (nicht default), das hatte ich extra geprüft. Wann und warum sich das geändert hat, sodass jetzt wieder default statt -2 enthalten ist, verstehe ich nicht. Passiert das vielleicht beim Booten des neu erstellten Kernels?
So ganz blicke ich bei Deinem Installieren, Verschieben, Kopieren, usw. nicht mehr durch. Irgendwo laeuft da etwas schief, aber das ist alles reichlich unuebersichtlich.
Nun, was ich kopieren nenne ist im Konqueror (als Datei-Manager) ein einfaches "cut & paste" hallo Thomas Vielen Dank für Deine treue Unterstützung. Da bilde ich mir ein, ich kann Kompilieren und dann sowas ;-) Gruß Rolf
Rolf Hoff wrote:
[...] wieselsdachsbau:~ # zcat /proc/config.gz | tail -n 8 # # Build options # CONFIG_SUSE_KERNEL=y CONFIG_CFGNAME="2" CONFIG_RELEASE="7.75" CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y wieselsdachsbau:~ #
Das ist die Konfiguration, die zu Deinem aktuell gebooteten Kernel passt. Wie man sieht, steht dort auch ein entsprechendes CFGNAME und ein entsprechendes RELEASE, was Dir letztendlich den Namen 2.6.5-7.75-2 liefert. Es kann auch nicht anders sein, weil diese Pseudo-Datei /proc/config.gz ja direkt vom gebooteten Kernel erzeugt wird.
[...] Wie am 28.06.04 berichtet: (auszugsweise Wiedergabe)
- - - - - s n i p p 3) Statt "make cloneconfig bzw. make oldconfig habe ich eine eigene .config-Datei nach /usr/src/linux kopiert, geöffnet, um darin Build Options - CONFIG_ CFGNAME="default" zu ändern in ="2" und abschließend gespeichert. Alsdann habe ich ausgeführt: "make prepare"
- - - - - s n i p p
Ich wuerde in solchen Faellen wie von Dir hier beschrieben immer a) ein "make mrproper" durchfuehren, dann b) die Konfiguration nach .config kopieren, dann c) die Konfigurationsdatei direkt editieren, dann d) ein "make oldconfig" durchfuehren, und schliesslich e) ein "make prepare". Beim eigentlichen Konfigurieren mit "make xconfig" wuerde ich es anders machen, da wuerde ich a) ein "make mrproper" durchfuehren, dann b) die Konfiguration nach .config kopieren, dann c) ein "make oldconfig" durchfuehren, d) mit "make xconfig" (oder "make menuconfig") die Konfiguration abaendern oder fortfuehren, und schliesslich e) ein "make prepare" ausfuehren. In diesem Falle kann man dann auch die "Build Options" bequem beim Konfigurieren selbst setzen. Falsch waere Deine Vorgehensweise allerdings dann, wenn die kopierte .config nicht exakt zum Kernel-Source passt, wenn also der zu konfigurierende Kernel neue Features hat etc. - Deine Vorgehensweise geht _nur_, wenn Du die .config von einem identischen Kernel-Source aus einem anderen Verzeichnis kopiert hast. Ansonsten ist _immer_ ein "make oldconfig" auszufuehren, da ja damit die kopierte Konfiguration erst um neue Features erweitert und evtl. bereinigt wird, sodass sie zum neuen Source passt!
[...] Nach dem "make prepare" lautete version.h auch 2.6.5-7.75-2 (nicht default), das hatte ich extra geprüft.
Dann hat die Funktionsweise, wie sie immer beschrieben wurde hier auf der Liste, auch funktioniert.
Wann und warum sich das geändert hat, sodass jetzt wieder default statt -2 enthalten ist, verstehe ich nicht. Passiert das vielleicht beim Booten des neu erstellten Kernels?
Nein. Am Kernel-Source (!) wird normalerweise nichts veraendert beim Booten. Das waere ja auch schlimm. Eigentlich kannst Du das fast nur selbst (wenngleich vielleicht unabsichtlich) gemacht haben, indem Du evtl. an einer falschen Stelle mal ein "make cloneconfig" o.ae. eingegeben hast...
[...] Nun, was ich kopieren nenne ist im Konqueror (als Datei-Manager) ein einfaches "cut & paste"
Nun, Du schriebst etwas der Form "cp dir1 dir2" in Deiner Mail, das sah doch sehr nach Kommandozeilenkopieren aus und nicht nach einer Kopieraktion im konqueror, das war nicht zu erkennen... Ich mache solche Dinge ja lieber an der Kommandozeile, zumal Du diese Verzeichnisse in /usr/src ja nur als root kopieren kannst, und da wuerde ich mir den Einsatz von konqueror dann doch zwei Mal ueberlegen. Ein entsprechender Thread fand vor kurzem statt (Einsatz von GUI oder graphischem Login fuer root).
[...] Da bilde ich mir ein, ich kann Kompilieren und dann sowas ;-)
Man hat nie ausgelernt, weder im Leben noch bei Linux. Auch ich lerne staendig neue Dinge beim Kernel... Gruesse, Th.
Rolf Hoff wrote:
[...]
Nach dem "make prepare" lautete version.h auch 2.6.5-7.75-2 (nicht default), das hatte ich extra geprüft.
Dann hat die Funktionsweise, wie sie immer beschrieben wurde hier auf der Liste, auch funktioniert.
Wann und warum sich das geändert hat, sodass jetzt wieder default statt -2 enthalten ist, verstehe ich nicht.
[ . . . .] hallo Thomas auch ein hallo an alle dank Deiner intensiven Beratung kann ich jetzt (z.B.) die Kernel-Source-2.6.5-7.75 problemlos compilieren. Mit dem neuen Kernel kann man auch problemlos booten. Nur konnte mit dem Kernel z.B. "antivir" und/oder "nvidia" nicht installiert werden. Das lag daran, dass in /lib/modules/kernel-version/build/include/ linux/version.h "UTS-RELEASE" nicht dem aktuellen (und gebootetem) Kernel entsprach. Jetzt kenne ich den Grund für den Fehler und die L Ö S U N G, wie der Fehler vermieden werden kann: Anders als bei den Kernel-Source-2.6.4-* gehört jetzt (bei SuSE) zu den Kernel-Source-2.6.5-7.75 das Verzeichnis "Kernel-Source-2.6.5-7.75-obj" Ohne die Dateien in *-obj kann der Kernel nicht mehr compiliert werden. Aber, wenn ich das Makefile in den Kernel-Source (am Ende) richtig verstanden habe, dann kann build die Dateien in *-obj nicht mit den nötigen Informationen versorgen. Zumindest bei dem von mir verwendeten Kernel-default (Uniprozessor) sind davon (mit Einfluß auf das Compilieren) folgende Dateien betroffen: *-obj/i386/default/.config und /Makefile *-obj/i386/default/include/linux/autoconf.h und version.h Ich kann nicht mit Bestimmtheit sagen, ob die Datei ./version.h (aus *-obj) beim Compilieren mit den Angaben des Kernels aktualisiert wurde. Wenn ja, dann wurde sie aber - wie auch alle anderen Dateien "version.h" - überschrieben (wahrscheinlich von der "autoconf.h" in *-obj, die mit Sicherheit nicht während des Compilierens aktualisiert wird.) Andere Dateien in *-obj usw können natürlich auch betroffen sein, das habe ich aber nicht weiter geprüft. Und nun mein Vorschlag für die L Ö S U N G : Zur Vermeidung einer falschen oder nicht eindeutigen Bezeichnung der (neuen) Kernel-Source kopiere ich in /usr/src "linux-2.6.5-7.75" und benenne sie dabei um in z.B. "linux-2.6.5-7.75-1" (Bei dieser Handhabung bitte nur die Original-Kernel-Source als Ausgangsbasis für das Kopieren verwenden) Die Meinung über diese Handhabung kann sicher unterschiedlich sein. Ich habe nur gute Erfahrungen damit. Gleichzeitg kopiere ich "linux-2.6.5-7.75-obj" (wie vorstehend) als "linux-2.6.5-7.75-1-obj" . Alsdann berichtige ich die Links. Der neue Kernel, der nunmehr compiliert werden soll hat jetzt die Bezeichnung "linux-2.6.5-7.75-1" mit "*-1-obj" Wenn dann nach dieser Vorbereitung und durch make mrproper, make oldconfig (oder make cloneconfig), make xconfig (oder make menueconfig) und make prepare für folgende Handhabungen die Grundlagen feststehen, mache ich folgendes zur Vermeidung des hier in Rede stehenden Fehlers: 1) Ich ändere im linux-2.6.5-7.75-1-obj/i386/default/Makefile die Kernel-Bezeichnung in "Linux-2.6.5-7.75-1" 2) Ich lösche die Dateien linux-2.6.5-7.75-1-obj/i386/default/.config und linux-2.6.5-7.75-1-obj/i386/default/include/linux/ autoconf.h und version.h und ersetze sie durch die gleichlautenden Dateien aus /usr/src/linux-2.6.5-7.75-1/.config /usr/src/linux-2.6.5-7.75-1/include/linux/autoconf.h und version.h Danach sollte in "version.h" die Bezeichnung für "UTS_RELEASE" nicht mehr mit Angaben überschrieben werden, die nicht mit dem aktuellen Kernel übereinstimmen. Gruß Rolf
Rolf Hoff wrote:
hallo
ich habe schon mehrfach erfolgreich nvidia unter einem selbst gebauten Kernel installiert.
Jetzt habe ich die kernel-source-2.6.5-7.75-default als 2.6.5-7.75-2 selbst kompiliert und kann auch damit booten:
ro999:~ # uname -r 2.6.5-7.75-2 ro999:~ #
Nur diesmal kriege ich nvidia nicht zum Laufen. Die Fehlermeldungen laut nvidia-installer.log lauten:
- - - - - - - - - - s n i p p [ . . . .] -> Kernel module linked successfully. ERROR: Unable to load the kernel module 'nvidia.ko'. This is most likely because the kernel module was built using the wrong kernel source files. Please make sure you have installed the kernel source files for your kernel; [ . . . ] -> Kernel module load error: insmod: error inserting ... u.s.w.
ich hatte mal das gleiche Problem bei der SuSE8.1 und da lag es daran das ich nen Athlon hatte. Hört sich komisch an aber es liegt an den Kernel-Sourcen wenn Du Dir von NVIDIA die Treiber holst. Damals hatte ich mir dewegen nen kleines Skript geschrieben: ---------schnipp---------- #!/bin/sh ################################################ # Achtung ! # - Kernel-Sourcen muessen installiert sein # - NVIDIA Treiber im Skriptverzeichnis ################################################ cp /boot/vmlinuz.autoconf.h /usr/src/linux/include/linux/autoconf.h cp /boot/vmlinuz.version.h /usr/src/linux/include/linux/version.h export IGNORE_CC_MISMATCH=yes sh NVIDIA-Linux-x86-1.0-4496-pkg2.run ----------schnupp---------------- vielleicht gehts ja auch bei Dir... Gruß Alex
Alex K. wrote:
[...] ich hatte mal das gleiche Problem bei der SuSE8.1 und da lag es daran das ich nen Athlon hatte. Hört sich komisch an aber es liegt an den Kernel-Sourcen wenn Du Dir von NVIDIA die Treiber holst. [...]
Nein. Wenn die Kernel-Sourcen richtig fuer den laufenden Kernel konfiguriert sind, liegt es daran definitiv nicht. Der Unterschied zwischen *-default und *-athlon ist ja nicht der Kernel-Source selbst, sondern dessen Konfiguration. Beim Einen wird ein anderer Prozessortyp ausgewaehlt, das ist mehr oder weniger alles. Das schlaegt sich nach dem damals von SuSE verwendeten Makefile allerdings in einigen Dateien nieder, z.B. version.h. Mit einem "make cloneconfig && make dep" ist der Kernel-Source aber korrekt fuer den laufenden Kernel konfiguriert und dann passt das auch... Ich habe den NVIDIA-Treiber bereits zig Mal installiert, mit P4 Prozessoren und mit AMD Prozessoren, mit Vanilla-Kerneln und mit SuSE-Kerneln, mit Kerneln der 2.4er und der 2.6er Serie, und das hat noch immer geklappt. CU, Th.
Thomas Hertweck schrieb: [ . . . .] hallo Thomas auch an alle
Nein. Wenn die Kernel-Sourcen richtig fuer den laufenden Kernel konfiguriert sind, liegt es daran definitiv nicht. [ . . . .] Der Unterschied zwischen *-default und *-athlon ist ja nicht der Kernel-Source selbst, sondern dessen Konfiguration.
[ . . .]
Mit einem "make cloneconfig && make dep" ist der Kernel-Source aber korrekt fuer den laufenden Kernel konfiguriert und dann passt das auch... Ich habe den NVIDIA-Treiber bereits zig Mal installiert, mit P4 Prozessoren und mit AMD Prozessoren, mit Vanilla-Kerneln und mit SuSE-Kerneln, mit Kerneln der 2.4er und der 2.6er Serie, und das hat noch immer geklappt.
CU, Th.
ich befürchte, ich bin aufgrund Deiner obigen Angaben meinem Fehler auf der Spur. Um das zu klären muss ich mich wohl erst mal blamieren und dann ganz dumm fragen: Vorgabe: Bei der Erstinstallation von SuSE-9.1 habe ich außer den "Kernel-Sourcen" (Linux-2.6.4-52-default) auch das Paket "Kernel-default" (Version 2.6.4-52) installiert. Auch bei einem Update vom SuSE-ftp-Server habe ich immer den Kernel-default und die Sourcen installiert. Wie ich jetzt festgestellt habe, werden ja vom Kernel-default unter /lib/modules die Verzeichnisse "precompiled" (für "kernel-version") und "scripts" eingerichtet. Für den Kernel "2.6.5-7.75" habe ich aber nur die Kernel-Source-2.6.5-7.75 (default) heruntergeladen und installiert (weil ich der Meinung war, das ja bereits ein Kernel läuft (2.6.4-52-3) und ich vor Installation des neuen Kernels 2.6.5-7.75-default ohnehin erst die Kernel-Source- 2.6.5-7.75 (-default) mit einer neuen Extra- Versions-Angabe kompilieren wollte.) Da ich keinen Kernel-default neben den Sourcen heruntergeladen habe und auch nicht installiert habe, fehlen nun ja für 2.6.5-7.75-default die Verzeichnisse "precompiled" und "scripts". Ich denke, alle anderen Verzeichnisse des Kernel-default unter /lib/modules werden beim Kompilieren der Sourcen ohnehin ersetzt. Was ist nun richtig? Muss ich tatsächlich immer neben den Kernel-Source auch den Kernel-default installieren? Wenn ja, wird der Kernel-default auch mit rpm -ihv --force --nodeps *.rpm installiert? Und wie verhält sich das dann bei Verwendung von *.tar.gz (o.ä.) Für alle Hilfen dankbar hoffe ich, nicht von allen ausgelacht zu werden. Gruß Rolf
Rolf Hoff wrote:
[...] Vorgabe: Bei der Erstinstallation von SuSE-9.1 habe ich außer den "Kernel-Sourcen" (Linux-2.6.4-52-default) auch das Paket "Kernel-default" (Version 2.6.4-52) installiert.
Das kann schon mal nicht sein. Das Paket mit dem Kernel-Source kann kein "default" im Namen haben, da es von einer Konfiguration voellig unabhaengig ist. Wie Du leicht in [1] nachschauen kannst, heisst das Paket mit dem Kernel-Source bei der SuSE 9.1 Distribution (ohne Update) kernel-source-2.6.4-52.i586.rpm, das Paket mit dem SuSE Standardkernel (ebenfalls 9.1 Distribution ohne Update via YOU) kernel-default-2.6.4-52.i586.rpm.
[...] Auch bei einem Update vom SuSE-ftp-Server habe ich immer den Kernel-default und die Sourcen installiert.
Das ist ja auch gut so, sofern Du die richtigen Pakete genommen hast.
[...] Wie ich jetzt festgestellt habe, werden ja vom Kernel-default unter /lib/modules die Verzeichnisse "precompiled" (für "kernel-version") und "scripts" eingerichtet.
Ja, diese Verzeichnisse werden durch SuSE angelegt, das ist so eine Eigenart. Ich benutze hier einen Vanilla-Kernel, mit dem bin ich weitaus zufriedener, da gibt es die Verzeichnisse nicht - sie sind nicht Teil des eigentlichen Kernels, sondern eines gewissen SuSE Mechanismus, der mir allerdings etwas abhanden geht. Beide Verzeichnisse, precompiled und scripts, sollten aber irgendwo versionsspezifische Unterverzeichnisse haben, AFAIK. Nun ja, ich jedenfalls brauche diese Verzeichnisse nicht.
[...] Für den Kernel "2.6.5-7.75" habe ich aber nur die Kernel-Source-2.6.5-7.75 (default) heruntergeladen und installiert (weil ich der Meinung war, das ja bereits ein Kernel läuft (2.6.4-52-3) und ich vor Installation des neuen Kernels 2.6.5-7.75-default ohnehin erst die Kernel-Source- 2.6.5-7.75 (-default) mit einer neuen Extra- Versions-Angabe kompilieren wollte.)
Wenn Du einen Kernel selbst compilierst, dann brauchst Du _nur_ den Quellcode, kein Binaer-RPM mit fertig compiliertem Kernel. Wie aber oben schon geschrieben: die Angabe "(default)" beim _Kernel-Source_ macht keinen Sinn!
[...] Muss ich tatsächlich immer neben den Kernel-Source auch den Kernel-default installieren?
Nein, garantiert nicht.
[...] Und wie verhält sich das dann bei Verwendung von *.tar.gz (o.ä.)
Den SuSE-Kernel-Source gibt es leider nicht mehr als Tar-Archiv. Du kannst hoechstens rpm2cpio verwenden, um das Installieren per RPM zu verhindern. Gruesse,, Th. [1]ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/9.1/suse/i586
participants (3)
-
Alex K. -
Rolf Hoff -
Thomas Hertweck