Nach kernel compilieren fehlen alle Module

W

Wolfgang

Foren Gott
Hallo
Ich habe jetzt mal ein paar generelle Fragen zum kernel, die ich in keiner manpage beantwortet bekomme.
Überall kann man lesen wie ein Kernel kompiliert wird.
Auf Debianart ( wie bei mir zutreffend) oder auch konventionell.
Allerdings ist mir das bisher ( so ca 20 Versuche) nicht gelungen einen bootfähigen Kernel zu installieren.
Das Problem ist letztendlich immer das gleiche:
Nachdem die Kompilierung erfolgt ist, der Bootloader konfiguriert und das Kernelpaket installiert ist, bootet der Kernel. Allerdings werden keine essentiellen Module gefunden.
Das Verzeichnis /lib/module/$(uname -r) ist vorhanden.
Dort sollte ja nach meinem Verständnis nach den Modulen gesucht werden.
Was mir nicht klar ist:
1) im einzig bootablen Modulverzeichnis welches orginal nach der Installation erstellt wurde sind symbolische Links
build -> /usr/src/linux-2.6.7
source -> /usr/src/linux-2.6.7/include

Soweit klar, aber diese Links existieren in den von mir selbst installierten Kerneln entweder garnicht, oder nur der build.
Erzeuge ich ein Kernelpaket nach Debianart
make-kpkg kernel_image wird mir ein Paket erzeugt, welches ich anschließend mit
dpkg -i kernel_paket_name.dep installieren kann.
All das ist machbar, und auch zu Fuß ( grub anpassen usw) schon erfolgreich von mir erledigt.
Am Ende stehe ich aber wieder vor dem Problem, dass keine Module gefunden werden, die zum Kernel gehören.
Wo liegt da das Problem, vergesse ich irgendwo einen Link zu setzen?
Es muss doch irgendwie möglich sein, dem System zu sagen wo es die Module findet?
make module_image bringt keinen Erfolg, die Links in den Modulverzeichnissen selber setzen auch nicht?
Nun bin ich am Ende mit meinem Latein ( Verständnis)
Normalerweise erarbeite ich mir viele Dinge selbst, aber hier komme ich wirklich nicht mehr weiter.
Ich hoffe mir kann mal jemand den erleuchtenden Hinweis geben.
Und ja, ich habe sehr viele Website aufgesucht, stundenlang alle möglichen Hinweise gelesen.
Alle vorgeschlagenen Varianten funktionieren bei mir nur bis zum Stichpunkt Module. es wird immer nur das geladen, was ich fest einbinde.
Das kann aber nicht die Lösung sein alles einzubinden.

Danke schonmal
Gruß Wolfgang
 
Hast du die Module auch compiliert?
Code:
make modules
make modules_install
 
Hallo
Also auf Debainart ist das laut man make-kpkg erledigt.

...
kernel_image
This target produces a Debian package of the Linux kernel source image, and any modules configured in the kernel configuration file .config.
...


Das Verzeichnis unter /lib/modules/$(uname -r) für den neuen Kernel wird auch erzeugt!
Nur werden diese wie beschrieben beim booten nicht gefunden.
Habe mal einen Kernel gebaut, der exakt die gleiche Konfiguration wie der laufende hat.
Das ergebnis ist wie beschrieben nicht bootable, weil keine Module gefunden werden.
Mir ist das völlig unklar.

Gruß Wolfgang
 
Wenn in /lib/modules/$(uname -r) keines der Unterverzeichnisse kernel und pcmcia ist, sowie die ganzen modules.* Dateien fehlen, dann sieht das aber so aus, als ob die Module nicht kompiliert wurden.
 
Es fehlen nicht alle Dateien.
beispielsweise sieht es nach Kompilierung von kernel2.6.12-rc3 so aus:

/lib/modules/2.6.12-rc3.2005.04.29.01.2

lrwxrwxrwx 1 root root 25 Apr 30 16:51 build -> /usr/src/linux-2.6.12-rc3
drwxr-xr-x 10 root root 4096 Apr 30 16:51 kernel
-rw-r--r-- 1 root root 20146 Apr 30 16:51 modules.alias
-rw-r--r-- 1 root root 69 Apr 30 16:51 modules.ccwmap
-rw-r--r-- 1 root root 53114 Apr 30 16:51 modules.dep
-rw-r--r-- 1 root root 665 Apr 30 16:51 modules.ieee1394map
-rw-r--r-- 1 root root 798 Apr 30 16:51 modules.inputmap
-rw-r--r-- 1 root root 158 Apr 30 16:51 modules.isapnpmap
-rw-r--r-- 1 root root 29856 Apr 30 16:51 modules.pcimap
-rw-r--r-- 1 root root 38610 Apr 30 16:51 modules.symbols
-rw-r--r-- 1 root root 1999 Apr 30 16:51 modules.usbmap
lrwxrwxrwx 1 root root 25 Apr 30 16:51 source -> /usr/src/linux-2.6.12-rc3

Im Verz kernel liegen dann:

/lib/modules/2.6.12-rc3.2005.04.29.01.2

drwxr-xr-x 3 root root 4096 Apr 30 16:51 arch
drwxr-xr-x 2 root root 4096 Apr 30 16:51 crypto
drwxr-xr-x 17 root root 4096 Apr 30 16:51 drivers
drwxr-xr-x 24 root root 4096 Apr 30 16:51 fs
drwxr-xr-x 3 root root 4096 Apr 30 16:51 lib
drwxr-xr-x 18 root root 4096 Apr 30 16:51 net
drwxr-xr-x 2 root root 4096 Apr 30 16:51 security
drwxr-xr-x 6 root root 4096 Apr 30 16:51 sound

Wenn ich diesen kernel boote, komme ich bis zum Login und dann friert alles ein.
Die /var/log/boot zeigt mir, dass keine Module gefunden werden die nicht direkt eingebunden sind. Das ist der Grund, warum es dort nicht weiter geht.

Im Verzeichnis des aktuell laufenden kernel sieht es so aus:

/lib/modules/2.6.7-1-386

drwxr-xr-x 2 root root 4096 Sep 15 2004 boot
lrwxrwxrwx 1 root root 20 Apr 29 17:15 build -> /usr/src/linux-2.6.7
drwxr-xr-x 2 root root 4096 Sep 15 2004 initrd
drwxr-xr-x 10 root root 4096 Sep 15 2004 kernel
-rw-r--r-- 1 root root 135023 Apr 30 18:13 modules.alias
-rw-r--r-- 1 root root 69 Apr 30 18:13 modules.ccwmap
-rw-r--r-- 1 root root 232588 Apr 30 18:13 modules.dep
-rw-r--r-- 1 root root 517 Apr 30 18:13 modules.ieee1394map
-rw-r--r-- 1 root root 1061 Apr 30 18:13 modules.inputmap
-rw-r--r-- 1 root root 16427 Apr 30 18:13 modules.isapnpmap
-rw-r--r-- 1 root root 128318 Apr 30 18:13 modules.pcimap
-rw-r--r-- 1 root root 102253 Apr 30 18:13 modules.symbols
-rw-r--r-- 1 root root 151505 Apr 30 18:13 modules.usbmap
lrwxrwxrwx 1 root root 26 Apr 29 19:32 nvidia -> /lib/modules/2.6.7/nvidia/
lrwxrwxrwx 1 root root 28 Apr 29 17:08 source -> /usr/src/linux-2.6.7/include

Nur dieser Kernel wird gebootet.
Wobei auch hier das nvidia Modul nicht gefunden wird??
Ich komme irgendwie nicht weiter.
Würde gerne endlich mal den Fehler den ich sicher mache rausbekommen.

Danke schonmal und Gruß
Wolfgang
 
NAchdem du nen neuen KErnel installierst is das mit NVidia klar: das fliegt nach jedem Compilieren. daher musst es nach jeder Kernel änderung neu installieren.
 
Zico schrieb:
NAchdem du nen neuen KErnel installierst is das mit NVidia klar: das fliegt nach jedem Compilieren. daher musst es nach jeder Kernel änderung neu installieren.
Hallo
Ja, ne ist klar :D
Das Dumme ist nur, dass ich den neuen Kernel ja nicht zum Laufen bekomme.
Das meint, der nvidia ist auf den aktuell laufenden kernel installiert.
;)

Außerdem gibt es ja noch die Möglichkeit beim
make kpkg --added_modules foo
die im Verz /usr/src/modules liegenden Module gleich mit einzubinden.
Gefunden wird er trotzdem nicht.
Aber das ist erstmal nebensächlich.
Die Frage ist eher warum generell die Kernel die ich baue keine Module finden.
Der installierte ( bei der Installation des Systems) findet ja auch seine eigenen Module .
Gruß Wolfgang
 
Zuletzt bearbeitet:
Achso, sorry ich gin davon aus, dass du Nvidia nciht wieder installiert hättest (wär zumindest ein Problem weniger gewesen)
So wie ich das bisher verstanden hab, hast du den Kernel nach Debianart installiert.
Hast du denn auch schonmal versucht den vanilla kernel von kernel.org selbst zu backen?
Vllt. hast du damit mehr erfolg
 
:D :D :D
Was soll ich sagen, habe eben den x-ten Kernel gebaut.
Anfangs auch auf konventionelle Art, die letzten 20-30 nur noch auf Debainart.
- lässt sich besser verwalten und auch deinstallieren.

Dabei habe ich diesmal einen auf dieser Kiste vorinstallierten Kernel aus einem anderen Sarge-System genommen und gnadenlos auf
make oldconfig gesetzt.
Vorher noch ein paar Sachen, die ich wirklich nicht brauche per vi aus der config rausgeschmissen.
Installiert wie immer und gebootet.
Und ich war sprchlos, der Kernel bootet durch, wenngleich auch blind bis zum Login ( also nachdem X gestartet wird)
Die Bootoption vga=792 scheint aus mir unerklärlichen Gründen nicht zu gehen.

Allerdings habe ich dabei ein häßliches initrd mit gebaut.
Na immerhin ist das der erste Kernel der wirklich bootet.
:D
Weiß aber immernochnicht, warum es vorher nicht ging.

Werde das nochmal von einem vanilla zu Fuß machen.

Trotzdem bin ich mir noch nicht ganz im Klaren, welche Links gesetzt sein müssen in den Modulverzeichnissen und vor allem auch in den Kernel-headern?
Überall liest man verschiedene Dinge darüber.
Noch eine Verständigungsfrage:
Wenn ich die Kernel-sources installiert habe, habe ich doch die Kernel-header schon mit dabei. Warum also brauche ich die Kernel-header noch extra zum Kompilieren?
Einige selbst kompilierte Software ließ sich nicht ohne enen Link auf /usr/src/kernel-header kompilieren?
Reicht da nicht ein korrekt gesetzter Link auf die Kernel-sourcen des aktuell laufenden Kernel?

Danke
Gruß Wolfgang
 
... weil alle Debian-"Standard"-Kernel ne initrd verwenden.

kernel-header und kernel-sourcen sind zwei paar Schuhe.

Die kernel-header sind die speziellen header-files eines compilierten kernels mit den entsprechenden Konfigurationsoptionen.

Die sourcen sind dagegen "Rohmaterial" und für kernel-spezifische Sachen halt "unbrauchbar" ... ohne Nachbearbeitung.
 
Zuletzt bearbeitet:
Hallo
Die initrd wird als standard verwendet, aber nicht als standard bei der Erzeugung des kernel_images.
Da gibt es sogar noch eine extra Beschreibung wie diese Warnmeldung ausgeblendet werden kann.
Nach weiteren 8 Versuchen (!) auf meiner relativ langsamen Kiste bin ich nun soweit, dass ich den ertsen Kernel der ohne initrd auskommt erzeugt habe.
Mit der Version 2.6.8 war das möglich, mit der 2.6.11 aber nicht.
Die 2.6.11 bootet dann zwar selbst mit initrd, diese wird auch geladen aber alles was ich in den Kernel fest eingebaut habe funktioniert nicht.
Alle verwendeten Filesysteme sind fest einkompiliert, aber ausser dem root / findet er keinerlei andere Partitionen mehr? :think:
Desweiteren kann ich nur ohne Option vga=791 booten, obwohl ich nur den standard framebuffer und vag16 geladen habe. extra keine nvidia/Riva Unterstützung, da sich damit das nvidiamodul nicht erzeugen lässt.
Der letzte Kernel ohne initrd lieft diesmal, nur leider fehlte ihm irgendetwas für die pppoe.
Fazit kein Internet. Nun bin ich auf der Suche welches pppoe-modul ich vergessen habe.
Naja also nach weiteren XX Versuchen wird es ja irgendwann mal klappen.

Was die Kernelheader betrifft:
Wenn ich aus den Kernel-sourcen die Kernel-header erzeugen kann, dann sind diese ja wohl darin enthalten.
Oder wie sonst ist das möglich?
Es sind ja letztendlich nur die per #include einzufügenden normalen header.h Dateien.

Irgendwie ließt man da zu viele verschiedene Infos und Anleitungen die nicht übertragbar sind und sich teilweise widersprechen.

Die letzten Infos waren sogar, dass make-kpkg einen bug beinhaltet.

Es bleibt weiterhin so bei mir:
  1. dass Module nicht gefunden werden.
  2. dass ein Kernel version >2.6.8 nicht zum Laufen zu bringen ist ( mit und ohne initrd)
  3. dass keinerlei vga=xxx bootparameter verwendbar sind.


Fragen über Fragen

Ich werde weiterkämpfen 8)

Seltsamerweise hatte ich auf einer Slackware 10.0 nicht derlei Probleme.(gut war Kernel 2.4.27)
Dort ging alles auf Anhieb.
Mag aber Debian trotzdem mehr.

Gruß Wolfgang
 
Wolfgang_1 schrieb:
Hallo
Die initrd wird als standard verwendet, aber nicht als standard bei der Erzeugung des kernel_images.
Da gibt es sogar noch eine extra Beschreibung wie diese Warnmeldung ausgeblendet werden kann.
Nach weiteren 8 Versuchen (!) auf meiner relativ langsamen Kiste bin ich nun soweit, dass ich den ertsen Kernel der ohne initrd auskommt erzeugt habe.
... <snap>
Poste mal Deine config ... vielleicht ist es nur ne Kleinigkeit ...
Und die Ausgabe von lspci wäre noch interessant.
Was die Kernelheader betrifft:
Wenn ich aus den Kernel-sourcen die Kernel-header erzeugen kann, dann sind diese ja wohl darin enthalten.
Oder wie sonst ist das möglich?
Es sind ja letztendlich nur die per #include einzufügenden normalen header.h Dateien.
Das ist richtig ... so kam das bei Deinem letzten Post aber nicht rüber ;-)
Das Problem ist hier, dass der biuld bzw. source-Link im modules Verzeichnis nicht immer dahin zeigt, wo er hinzeigen soll ;-)
Die letzten Infos waren sogar, dass make-kpkg einen bug beinhaltet.

Es bleibt weiterhin so bei mir:
  1. dass Module nicht gefunden werden.
  2. dass ein Kernel version >2.6.8 nicht zum Laufen zu bringen ist ( mit und ohne initrd)
  3. dass keinerlei vga=xxx bootparameter verwendbar sind.


Fragen über Fragen

Ich werde weiterkämpfen 8)

Seltsamerweise hatte ich auf einer Slackware 10.0 nicht derlei Probleme.(gut war Kernel 2.4.27)
Dort ging alles auf Anhieb.
Sagen wir so ... ich nur den 2.6er seit 2.6.0 unter Debian (mit make-kpkg) und derlei Probleme hatte ich irgendwie nie ...
Also, schaun wir mal ...
 
Zwischenstand falls es überhaupt noch jemanden interessiert :brav:

;)

Das Netzproblem habe ich gelöst.
Nachlesn in der pppoe RFM sagte mir, dass dort ein MODUL erwartet wird, und es darf nicht fest in den Kernel kompiliert werden.
Gesagt getan und es funktioniert wieder.
Könnte man ja als Auswahlmöglichkeit bei künftigen Kernelconfigurationen als nur Modul anwählbar gestalten.
Immerhin nun schon den dritten Kernel ohne initrd.img zum Durchstarten gebracht.
:devil: 8)
Der Haken an dem verfluchten Link ist die verwendung der Option
--revision ohne --append-to-version
Erst damit wurden entsprechende /lib/modules/kernel-version-revision erzeugt.
Nun werden die Module auch gefunden, und wenn der nvidia erzeugt werden soll, kann man sich nicht auf die Verwendung von uname -r verlassen!
Das bedeutet, dass explizit die gleiche Option verwendet werden muss wie bei der Kernel_image - Kompilierung.
Also genau das Gleiche wie bei --append-to-version und --revision.
Das ist essentiell, sonst landen die Module in einen falschen Ordner.

Erzeugt habe ich letzendlich die Kernel und nvidiamodule mit folgenden Befehlen:
kernelsource und nvidia-kernel-source entpackt in /usr/src wie üblich
(cd /usr/src; tar -xjf kernel-source-2.6.8.tar.bz2&& tar -xzf nvidia-kernel-source.tar.gz
cd /usr/src/ kernel-source-2.6.8 kernel
cp ../goodconfig .config
make menuconfig
#konfigueriert, dabei eine alte config-Vorlage geladen.
make-kpkg clean #wichtig make clean reicht hier nicht, da sonst Probleme beim --revision auftreten!
make-kpkg --append-to-version -wolle.v3 --revision 2.6.8.wolle.3 kernel_image
make-kpkg clean
make-kpkg --append-to-version -wolle.v3 --revision 2.6.8.wolle.3 modules_image

so geht es und ein anschließendes
dpkg -i ../kernelpaket
dpkg -i ../modulpaket
installiert alles.
bootable war beides und der nvidia ließ sich laden.
Was bleibt an Problemen:
  1. Nach wie vor geht keine bootoption vga=79x
  2. mein Pinguin oben Links kommt natürlich auch nicht- bootlogo ist aktiviert. ;)
  3. nvidia 3D lässt sich nicht installieren.
Der letzte Punkt mit dem neusten Nvidiamodul bringt keine Aussagekräftige Fehlermeldung
Einzig Xserver Error 11 ?( :think:
Habe im Kernel schon nvidia deaktiviert und framebuffer auch.
Einzig vga wird verwendet.
Desweiteren bin ich etwas verwirrt, was die agpunterstützung betrifft.
Ich habe ein intel-Board mit einer AGP Nvidiagforce Grafikkarte.
Was ist denn nun richtig beim
driver/char/agp
intel-agp oder nvidia-agp ?(
Der Chipsatz vom Board für agp ist ja ein intel8XX
Deshalb verwende ich den. Aber selbst mit nvidia-agp kommt der Xserver nicht hoch.
Er lief aber beim ersten Start, bis zum nächsten Reboot.
An der XF86Config kann es kaum liegen, soinst wär der erste Start ja auch nicht gegangen?

Fazit es bleiben ungelöste Probleme
weitermachen :D
Gruß Wolfgang
 
Wolfgang_1 schrieb:

make-kpkg clean #wichtig make clean reicht hier nicht, da sonst Probleme beim --revision auftreten!
make-kpkg --append-to-version -wolle.v3 --revision 2.6.8.wolle.3 kernel_image
make-kpkg clean
make-kpkg --append-to-version -wolle.v3 --revision 2.6.8.wolle.3 modules_image
Kannst Du zu

make-kpkg clean
make-kpkg --append-to-version -wolle.v3 --revision 2.6.8.wolle.3 kernel_image modules_image

zusammenfassen.
Was bleibt an Problemen:
  1. Nach wie vor geht keine bootoption vga=79x
  2. mein Pinguin oben Links kommt natürlich auch nicht- bootlogo ist aktiviert. ;)
  3. nvidia 3D lässt sich nicht installieren.
Der letzte Punkt mit dem neusten Nvidiamodul bringt keine Aussagekräftige Fehlermeldung
Einzig Xserver Error 11 ?( :think:
Habe im Kernel schon nvidia deaktiviert und framebuffer auch.
Einzig vga wird verwendet.
Desweiteren bin ich etwas verwirrt, was die agpunterstützung betrifft.
Ich habe ein intel-Board mit einer AGP Nvidiagforce Grafikkarte.
Was ist denn nun richtig beim
driver/char/agp
intel-agp oder nvidia-agp ?(
Der Chipsatz vom Board für agp ist ja ein intel8XX
Deshalb verwende ich den. Aber selbst mit nvidia-agp kommt der Xserver nicht hoch.
Er lief aber beim ersten Start, bis zum nächsten Reboot.
An der XF86Config kann es kaum liegen, soinst wär der erste Start ja auch nicht gegangen?
Fazit es bleiben ungelöste Probleme
weitermachen :D
Gruß Wolfgang
Alles schön und gut ... aber die config wäre schon hilfreicher ...
Eigentlich wird es nicht empfohlen, ein "3D-Modul" und Framebuffer (vga=schalg-mich-tod) zu nutzen, da dann 2 verschiedene Technologien auf verschiedene Weise auf die Grafikkarte zugreifen und das ab und zu in die Hose gehen kann. Daher geht IMHO auch der Tux nicht.
Was Du allerdings mir "3D geht nicht" meinst, ist mir schleierhaft.
Die XF86Config-4 wäre hier hilfreich ...
IntelAGP ist das richtige ... hier geht's um dem "MoBo-Treiber" und nicht die Graka ...
 
Wenn Du externe Module, also die Nvdia-Module zusammen mit dem Stock-Kernel erzeugen willst,
dann solltest du

make-kpkg modules-clean
make-kpkg modules-image --revision="blabla_append-to_usw"

nicht vergessen. Ein simples ´make modules´ nutzt dir in Verbindung mit kernel-package nichts.
Den ganzen append-to usw. Schwanz wuerde ich einfach mit --revision="einzigartigerNameXY" abkuerzen, sonst wirst irgendwann wahnsinnig vor lauter Optionen ;)
Ich habe hier (Linux prometheus 2.6.8 #1 Tue Mar 22 14:15:51 CET 2005 i686 GNU/Linux) selbst gerade mein Notebook mit Debian/sarge und nVidia FX5200go! vor mir, fuer das ich seit Toback die Kernels so baue.
Gegebenenfalls solltest du auch mkinitrd nicht vergessen - wenn das kernel.config Zeugs in /etc naemlich mit initrd konfiguriert ist, will kernel-package die Module in die /boot/initrd.img stecken und wartet darauf, dass du eine erstellst - diese Erkenntnis hat mich schon mal 3 Naechte und meinen Zweitverstand gekostet ;)
 
Hallo
So nach einer zweitägigen Pause habe ich das Modulproblem nun endgültig im Griff, und auch die Kernelkompilierung nebst den wichtigsten Fallen in die man tappen kann. ;)

Was bleibt sind nun weniger Probleme mit dem Kernel, als mehr mit der Grafik
-3d unterstützung der NvidiaGforce.
Allerdings auch der Bootsplash geht nur mit vga=normal ohne tux.

@YellowSPARC
Die append-to-version finde ich für mich recht brauchbar, da ich damit die vielen :D Kernel und Modul-pakete besser verwalten kann.

Bei Versionen ab 2.6.10 kann man bei der Konfiguration noch eine Revision angeben, was man aber nur verwenden sollte wenn man das nicht per Option beim make-kpkg benutzt.
Das wird nämlich nicht überschrieben, sondern zusätzlich angehängt. Das führt dann zu Problemen!

Mittlerweile habe ich Version 2.6.12-rc3 zum Laufen gebracht, aber auch dort bekomme ich keine Nvidia Module zum Laufen ( außer das glx und den "nv")

Das Thema sollte ich aber eventuell in einem neuen Thread unter Hardware posten.

Eine Frage -besser eure Einschätzungen- habe ich noch zum Kernel:
1) ist es wirklich besser, den Kernel ohne initrd zu basteln, und so viel wie möglich direkt einzubauen?
Ich habe den Eindruck, dass ein Kernel mit fast allem fest eingebaut langsamer bootet!
Der Kompromiss, ohne initrd und nur den essentiellen fest einzubauenden Modulen ( Filesystem etc.) ist trotzdem nicht messbar schneller als die Variante mit initrd.
Das ist mein Eindruck. Ist das bei euch anders?
Berücksichtigen muss ich aber, dass ich relativ langsame Hardware habe :
PIII 933MHZ ASUS CUSL2
Freu mich auf eure Einschätzungen bzw Ratschläge

Zum Thema Nvidia in einem anderen Thread , dort dann auch meine XF86Config-4 und die Fehlerlog von Nvidia.

Gruß Wolfgang
 
Prinzipiell macht es keinen Unterschied, ob modular oder monolit ... weder in den Boot-Zeiten noch im Betrieb. Eine initrd hat IMHO den Vorteil, dass man einen Kernel bauen kann, der auf vielen verschiedenen Plattformen läuft, indem man sämtliche Treiber (IDE, Sound, USB, was-weiß-ich) als Modul in die initrd packt und der Kernel sich quasi selber sucht, was er braucht. Hat aber auch den Nachteil, dass er einerseits zum bauen länger braucht und natürlich größer wird. Ansonsten ist es halt Geschmackssache. Der eine will halt lieber etwas probieren und läd die Module nach Bedarf ... der andere will sich um nichts kümmern und packt alles fest rein.
Auf meinem Server z.B. hab ichauch einen monoliten Kernel ... "historisch bedingt", da es früher mal Schwachstellen im Modul-Loader gab ... dem ging man so aus dem Weg.
Außderdem bin ich ab und zu vergesslich ... und wenn man dann stundenlang nach nem Fehler sucht, der auf ein nichtgeladenes Modul zurück zu führen ist ...
Das zu meinen "Erfahrungen" ...
 
Goodspeed1978 schrieb:
Außderdem bin ich ab und zu vergesslich ... und wenn man dann stundenlang nach nem Fehler sucht, der auf ein nichtgeladenes Modul zurück zu führen ist ...
Das zu meinen "Erfahrungen" ...

Naja. Stundenlang lang nach einem Fehler suchen und dann entdecken, dass man das entsprechende Modul nicht eincompiliert hat, ist aber fast noch ärgerlicher.
 
Naja, das passiert seltener ... schließlich weiß ich, was ich zusammen gefrickelt hab. Aber sich sicher zu sein, dass es da ist und funktionieren müßte ... blöde Sache das.
Aber egal ...
 
Hallo
Jo das ist mir aber trotzdem am Anfang mehrfach passiert.
Nun nach etlichen Kerneln weiß ich fast alles was rein muss. ;)
Lehrgeld zahlt wohl jeder, aber das ist die beste Art es wirklich zu lernen.

Habe nun endlich auch mein Nvidia Treiber erfolgreich zum Laufen gebracht. :D

Der Fehler war etwas, was ich einfach übersehen hatte.

Ich habe auf meinen Board eine onboard Graka, die ich aber im BIOS deaktiviert hatte.
Das Gerätemodul dafür habe ich aber als ladbares Modul mit kompiliert.
Seltsamerweise hat das pcihotplugmodul diesen trotzdem geladen und dafür auch das nvidia-glx nebst drm.
Nachdem ich das von Nvidia stammende Install-script habe laufen lassen, funktionierte immer erstmal alles wunschgemäß. Bis zum nächsten Reboot.
Nur hatte sich der aus den opensource modul stammende nvidia-glx als deamon eingetragen und startete jedesmal neu beim booten.
Das hat dann aber das Modul welches von Nvidia stammt vor die Wand laufen lassen, es lief ja schon ein anderes nvidia-glx!
Bis ich das rausgefunden hatte, hat es eine Weile gedauert.

Als ich das Modul dann mit Gewalt ;) entfernt habe - war ja immer in use von Boardgrakamodul - ging es dann problemlos.

Einzig was bleibt, ist die Frage warum ich bei der Bootoption vga=792 keine Bildschirmausgabe bekomme.
In der .config zum Kernel, habe ich lediglich vga16 angewählt, was auch gleich fest eingebaut ist.
Bei dem letzten 2.6.12-rc3 Kernel bekomme ich ab dem Moment wo der nvidia geladen wird plötzlich eine Ausgabe in dem gewünschten Modus.
Der tux ist zwar auch nicht zu sehen, auch alles was vor diesem modul kommt ist weg, aber danach geht es wie gewünscht.
Irgend etwas ist da faul. :think:
Das bleibt vorerst ein Rätsel für mich.
Der Bildschirm setzt plötzlich wieder ein mit der gewünschten Auflösung, ab dem Laden des nvidia.
Also heisst es weitersuchen.
Gruß Wolfgang
 

Ähnliche Themen

Debian Kernel kompilieren

Displayport + externer Monitor zeigt bei startx nichts erst bei DVI

System friert einfach ein

Ati-Treiber bringt mich um den Verstand

Ubuntu X / dbus problem

Zurück
Oben