Vorweg: ich habe gestern hier dienstlich auf einer SuSE 8.0 einen neuen SuSE 2.4.x Kernel installiert (per RPM). Danach war _kein_ NVIDIA-Grafikkartentreiber zu compilieren (und ich habe wahrlich Erfahrung im Compilieren von Kerneln und Modulen). Auch das Howto auf dem SuSE FTP-Server war voellig nutzlos. Das NVIDIA-Modul liess sich zwar stets erstellen, aber es konnte _nie_ geladen werden. Erst nachdem ich die Quellen des SuSE-Kernels selbst uebersetzt hatte, liess sich dann auch der NVIDIA-Treiber _ohne Probleme_ installieren. Ich weiss nicht, was SuSE mit ihren Kerneln macht, aber es hat mir mal wieder gezeigt, warum ich Kernel i.d.R. gleich von Hand erstelle oder Vanilla-Kernel nehme (leider hat man dienstlich nicht immer die Auswahl). Danke SuSE fuer 1h sinnlose Arbeit. Noch eine Bemerkung am Rande: obwohl die Konfiguration des fertigen SuSE-Kernels aus dem RPM-Paket exakt geklont und nur die Versionsangabe angepasst wurde, liessen sich einige Module nicht uebersetzen und das Compilieren brach mit einem Fehler ab. Ich weiss nicht, wie SuSE letztendlich die Kernel erstellt, aber so wie es aussieht muessen auch sie ein "make -k" verwenden, weil es sonst gar nicht geht... Emil Stephan wrote:

[...] Beim Booten eines selbstgebauten neuen Kernels erhielt ich Fehlermeldungen über unpassende Versionen von Modulen. So aus dem Gedächtnis aufgeschrieben: "Module version 2.6.5-7.95-emil preempt k6 does not match 2.6.5-7.95-default REGPARM". Nachdem ich das Verzeichnis /lib/modules/2.6.5-7.95-default in 2.6.5-7.95-default_O umbenannt hatte, beschwerte sich der Bootvorgang darüber, daß er die Datei modules.dep in /lib/modules/2.6.5-7.95-default nicht finden könne.

Das kann nicht funktionieren. Die Versionsangabe steckt ja nicht nur im Verzeichnisnamen, sondern im Modul selbst. Beim Laden wird ein Versionscheck gemacht (den man allerdings umgehen kann). Die Chancen sind aber relativ gross, dass gewisse Symbole fehlen, und dann laesst sich ein Modul eh nicht laden, selbst wenn die Versions- ueberpruefung umgangen wird.

Da war mir klar, daß er nicht die zu meinem selbstgebauten Kernel passenden Module zu laden versuchte, sondern die aus dem Verzeichnis des SuSe-Kernels.

Sieht so aus.

Die Module meines eigenen Kernels liegen in /lib/modules/2.6.5-7.95-emil. Danach habe ich dann die Anleitung zum Bau eines 2.6er Kernels von Thomas Hertweck gelesen und die Übersetzung des Kernels in zwei Schritte aufgeteilt. Sprich: Statt einfach nur make einzugeben habe ich zuerst "make bzImage" und anschließend "make modules" ausgeführt. Das hat auf meinem alten Rechner geholfen.

_Das_ (sprich: die Aufteilung) war es sicherlich nicht, denn ein "make" macht nichts anderes als intern "make bzImage" und danach "make modules" auszufuehren. Was Dir vielleicht geholfen hat, war die Tatsache, dass Du vorher bereits einen Versuch unternommen hattest und es im zweiten Anlauf dann nun besser ging.

Wie ich jetzt auf meinem Laptop feststellen mußte, war das aber wohl nicht der springende Punkt (oder das hüpfende Pferd, wie ein Ferrari-Fan sagen würde).

Ist logisch, siehe oben.

Was hatte ich nun zwischendurch noch gemacht? A: Die Umbenennung von /lib/modules/2.6.5-7.95-default

Wird nicht funktionieren.

B: make distclean Auf meinem Laptop hat das Letztere geholfen. Es sieht danach aus, daß "make distclean" eine Datei abräumt, die dann neu erstellt werden muß. Diese Datei hat wohl die richtige Einstellung für das Laden der Module eingebracht. Aber welche Datei ist das ???

Ich gehe inzwischen dazu ueber, direkt nach dem Entpacken der Quellen ein "make mrproper" durchzufuehren. Anschliessend wird per "make cloneconfig && make prepare" die Quellen fuer den laufenden Kernel konfiguriert und den Link /lib/modules/`uname -r`/build lasse ich auf das Verzeichnis mit meinen konfigurierten Quellen zeigen, nicht auf das seltsame zusetzliche Verzeichnis von SuSE in /usr/src - das hat hier nur Probleme gemacht. Das "make mrproper" verhindert auch das bereits beschriebene Problem "The .config file is a merged configuration; please remove it by hand before creating your own".

Das war aber nicht der Grund dafür, daß der Rechner beim Booten hängen geblieben ist. Ich hatte im Yast Sysconfig Editor unter Hardware->IDE->DEVICES_FORCE_IDE_DMA eingestellt, daß /dev/hda auf udma5 zu bringen sei. Erst nachdem ich das entfernt hatte, konnte ich das System mit dem neuen Kernel booten.

Ein "force DMA" sollte eigentlich nie noetig sein, wenn der Chipsatz voll unterstuetzt wird. In solch einem Falle sollte DMA automatisch benutzt werden. CU, Th. *ziemlich sauer ueber die SuSE-Kernel in letzter Zeit*