Hallo, On Sun, 17 Mar 2002, Heimo Ponnath wrote:
Hallo David,
Am Samstag, 16. März 2002 15:43 schrieb David Haller:
Hast du die modules.conf (fuer diesen Kernel) schon angepasst? Dann geht's naemlich automatisch ;)
Hm, jetzt weiss ich als relativer Linux-Neuling (und des Kompilierens bislang noch fast Unkundiger) nicht so ganz genau, was Du damit meinst.
Also erstmal, dass du die /etc/modules.conf fuer den Kernel, den du aktuell verwendest anpasst. Bis auf das Problem mit den Multiplen LUNs scheint's mit diesem Kernel ja zu funktionieren.
Ist es vielleicht diese Vorgehensweise hier: 1. make xconfig # Auswahl der einzelnen Kernel-Features 2. make dep # ? Vermutlich Auswahl der Sourcen ?
Nein, das erstellt die Abhaengigkeiten, die die Sourcefiles untereinander haben. 'dep' steht kurz fuer 'depend', was kurz fuer 'dependencies' (= Abhaengigkeiten) steht ;) 3. make clean
3. make bzImage # Kompilieren des Kernel 4. make modules # Kompilieren der Module
Jep.
und dann vor allem dieses hier:
5. make modules_install # ??
Das installiert die Module nach /lib/modules/<kernelversion>/.
Da dachte ich, daß irgendwie nun die modules.conf ins Spiel kommt??
Ne, die kommt erst zur Laufzeit in Spiel... Im Endeffekt ist die modules.conf dazu da, die Abhaengigkeiten von "device" und Modul aufzuloesen, und zwar spezifisch die Abhaengigkeiten, die nicht durch depmod automatisch aufgeloest werden koennen. Beispiel: Du hast nen SCSI-Adapter. scsi_mod (das von allen anderen scsi-Modulen wie sr_mod, sd_mod, etc. benoetigt wird) braucht einen "Hardware-Treiber". Bei sr_mod z.B. kann man eine Abhaengigkeit definieren, also dass sr_mod eben scsi_mod braucht. Und _diese_ Abhaengigkeit wird auch von depmod erkannt und aufgeloest. scsi_mod aber braucht einen Treiber fuer eine spezifische Hardware. Nun gibt es aber nicht ein Modul fuer die Hardware, sondern "viele", z.B. aic7xxx, tmscsim, u.v.a.m, und eben auch "ide-scsi". Woher soll aber depmod wissen, welcher dieser vielen Treiber z.B. fuer /dev/sr* zu verwenden ist??? Genau. Also muss man modprobe/insmod irgendwie sagen, dass dafuer z.B. ide-scsi gebraucht wird. Und um genau diese Abhaengigkeit zu definieren gibt's die modules.conf. Aehnlich ist's z.B. beim Sound. Woher soll der Kernel oder insmod wissen, welches Modul fuer /dev/dsp zu laden ist? Ergo schreibt man's in die modules.conf, dass eben z.B. das Modul 'mad16' zu verwenden ist: 'alias char-major-14 mad16'.
Oder geht es dabei um ein Anpassen von Hand,
Ja, darum geht es. Wobei es sich, wenn du mehrere unterschiedlich konfigurierte Kernel verwendest, dich mal an dem "Schema" zu probieren, das ich auf http://www.dhaller.de/linux/multikernel.html darstelle, also dass jeder Kernel seine eigene modules.conf bekommt, oder zumindest, dass die "konfliktverursachenden" Stellen in die Kernelspezifische Datei ausgelagert werden (Details gern auch per PM).
so wie ich das nach Deinem Vorschlag (13.3., 20:48) neulich ausgeführt habe:
alias scsi_hostadapter ide-scsi
pre-install sr_mod modprobe "-vk" ide-scsi alias block-major-11 sr_mod post-remove sr_mod modprobe "-r" ide-scsi
pre-install sg modprobe "-vk" ide-scsi alias char-major-21 sg post-remove sg modprobe "-r" ide-scsi
alias iso9660 isofs
Ja, genau diese Zeilen sind gemeint. Damit sagt man insmod/modprobe, dass es bitte erst ide-scsi laden soll ("pre-install") bevor es sr_mod laedt, da in diesem Fall "ide-scsi" der HW-Treiber ist... Bei nem echten SCSI-Adapter waere das eben z.B. nicht ide-scsi sondern aic7xxx. Also, wie geschrieben, die Empfehlung evtl. nen neuen Kernel zu kompilieren, gilt eigentlich nur fuer den Fall, dass dich die multiplen LUNs stoeren, und/oder das mit dem "ignore" fuer ide-cd nicht klappt. _Ich_ (mit meiner "Routine" beim Kernel backen) wuerde das zwar mal testen, ob das Problem an der MULTI_LUNS Einstellung liegt, aber fuer dich ist das wohl ein bisschen zu viel Aufwand, dich in das Thema einzuarbeiten... Es sei denn, du hast sowieso ein Interesse daran ;)
Jetzt ist hier etwas Ruhe eingekehrt und ich kann meine Computer aufschrauben. Dann tausche ich das DVD-Laufwerk mal gegen ein CD-ROM_Laufwerk aus dem anderen Computer aus und teste, ob es mit der jetzt eingestellten Konfiguration läuft.
Huh? Wieso dass denn?? Zu dem Leseproblem der Daten-CD, siehe die letzten Mails...
Hm. Ne CDR zufaellig? Und wie alt ist das LW?
Ne, eine ganz normale CD-ROM aus einer Bildersammlung, die ich auf dem Windows-Rechner schon oft benutzt habe. Das Laufwerk ist erst 5 Monate alt und kaum gebraucht, aber: Der ganze Computer hat nach dem vorangegangenen Abrauchen des Motherboards und des Prozessors und dem vollendeten Einbau der ganzen neuen Komponenten (Motherboard, Prozessor, Gehäuse) noch einen Autounfall mit Totalschaden (ja, Murphy läßt grüßen! Aber ich bin unverletzt aus dem Wrack gestiegen) mitgemacht, bei dem er völlig eingeklemmt war und mit Gewalt aus dem Autoschrott befreit werden mußte.
Oha!!! *URGSL* Hast du zufaellig Fotos von dem Crash/Rechner? Aber wie gesagt, ich wuerde auf jeden Fall erstmal andere (gepresste) CDs testen... Ist weniger Aufwand ;)
Bisher schien es mir - nach diversen Tests, bei denen das DVD-Laufwerk aber nicht so gründlich geprüft wurde - als wäre (oh Wunder) nur das Gehäuse gequetscht worden. Nun ist ja ein DVD-Laufwerk wesentlich feiner zu justieren als ein CD-ROM-Laufwerk (einfach wegen der höheren Packungsdichte auf dem Medium).
Jep.
Der Schlag beim Zusammenstoß kann sich auf die Mechanik des DVD-Laufwerks also schon verheerender ausgewirkt haben als auf die des anderen Laufwerks.
Also schraube ich halt jetzt ein wenig...
Ja, in dem Fall wuerde ich das auch "recht bald" testen ;) -dnh, auch schrauben wollend, die neue HDD soll ja mal eingebaut werden, aber die HDDs sollen schon ein wenig "Luft" bekommen, und dann diese Sch**** Kabellaengen und und und... Ich _hasse_ Laufwerk-rum- tauschereien... (bei 3-5 HDDs und 2 CD* wird's schwierig, was das physische Anordnen im Rechner angeht... ;( man versucht ja, moeglichst nicht alle 3 7.2kUPM HDDs direkt uebereinander einzubauen, sondern nen Schacht freizulassen... ) -- 80: Multitasking -- Nach dem Umstieg von einem verschwenderisch geschriebenen OS auf ein rationell geschriebenes, die gewonnene Performace ausgerechnet dann zu vernichten, wenn man Rechenpower braucht, weil cron.daily mitsamt updatedb, expire, tripwire und purgedata anläuft. (Kai Fett)