Modul automatisch laden

newer
Kopiergeschützte AudioCDs unter...

older
Kvdr - Kompilieren schlägt fehl -...

Ralph Müller

3 Jan 2004 3 Jan '04

21:25

Hallo, neuerdings benutze ich erfolgreich das intern-eingebaute Modem meines PCs. Leider muß ich nach jedem Booten erneut das entsprechende Modul (pctel.o) insmodden. Wie sag' ich's nun meiner Susi (7.0), daß sie dies doch bitte bei jedem Booten automatisch tun soll? Ist ein Startskript (/sbin/init.d/...) die geschickteste Möglichkeit? (Wie Startskripte aussehen ist mir bekannt.) Im voraus Danke für Hilfe. Ralph

Show replies by date

Thomas Hertweck

3 Jan 3 Jan

23:04

Ralph Müller wrote:

...

neuerdings benutze ich erfolgreich das intern-eingebaute Modem meines PCs. Leider muß ich nach jedem Booten erneut das entsprechende Modul (pctel.o) insmodden.

Wie sag' ich's nun meiner Susi (7.0), daß sie dies doch bitte bei jedem Booten automatisch tun soll? Ist ein Startskript (/sbin/init.d/...) die geschickteste Möglichkeit? (Wie Startskripte aussehen ist mir bekannt.)

Du solltest die Datei /etc/modules.conf anpassen, dass bei Bedarf das Modul automatisch geladen wird. Finde heraus, welches Device Dein Modem verwendet - Du brauchst die Major und Minor Number. Das kannst Du z.B. herausfinden, wenn Du fuer das entsprechende Device mal ein "ls -l /dev/<device>" machst, wobei Du <device> entsprechend ersetzen musst. Fuer das Device /dev/ttyS0 sieht es z.B. so aus bei mir: crw-rw---- 1 root uucp 4, 64 2003-03-14 14:07 /dev/ttyS0 ^^^^^ Diese Zahlen sind Major und Minor Number, hier also Major 4 und Minor 64. Nun editierst Du die Datei /ect/modules.conf und erstellst dort (falls nocht nicht fuer diese Major und Minor Number vorhanden) einen Eintrag: alias char-major-4-64 <modul> wobei <modul> durch den entsprechenden Namen des Moduls (ohne das Suffix) zu ersetzen ist. Entsprechend musst Du die Major und Minor Number anpassen fuer Deinen Fall. Das "char" steht dafuer, dass es sich um ein Character Device handelt, das sieht Du in obiger "ls -l" Ausgabe an dem "c" ganz vorne vor den Device-Rechten. Speichere die Datei ab und fuehre ein "depmod -a" aus. Danach muesste das Modul automatisch geladen werden, sobald auf das Device mit der eingetragenen Major/Minor Nummer zugegriffen wird. HTH, Thomson

Tobias Weisserth

23:46

Hallo,

...

Du solltest die Datei /etc/modules.conf anpassen, dass bei Bedarf das Modul automatisch geladen wird. Finde heraus, welches Device Dein Modem verwendet - Du brauchst die Major und Minor Number. Das ... ... automatisch geladen werden, sobald auf das Device mit der eingetragenen Major/Minor Nummer zugegriffen wird.

Ist das wirklich so kompliziert? Ich weiß ja nicht genau, wie das bei SuSE der Fall ist, aber ich trage ein Modul, das der Kernel automatisch laden soll, einfach in /etc/modules.autoload.d/kernel-[kernel version] ein und es wird dann beim Booten automatisch geladen. Ist das bei SuSE anders? Schau doch einfach mal, ob Du diese Dateien in Deinem /etc Ordner hast und wenn ja, dann kannst Du Dein Modul einfach dort eintragen und es ausprobieren. Gruß, Tobias

Thomas Hertweck

4 Jan 4 Jan

00:03

Tobias Weisserth wrote:

...

[...]

Wenn Du zitierst, lasse bitte eine Attribution-Line stehen, damit man weiss, wer was hier gesagt hat. Das folgende doppelt gequotete Zitat stammt von Thomas Hertweck (yes, that's me):

...

...
Du solltest die Datei /etc/modules.conf anpassen, dass bei Bedarf das Modul automatisch geladen wird. Finde heraus, welches Device Dein Modem verwendet - Du brauchst die Major und Minor Number. Das ... ... automatisch geladen werden, sobald auf das Device mit der eingetragenen Major/Minor Nummer zugegriffen wird.

Ist das wirklich so kompliziert? Ich weiß ja nicht genau, wie das bei SuSE der Fall ist, aber ich trage ein Modul, das der Kernel automatisch laden soll, einfach in /etc/modules.autoload.d/kernel-[kernel version] ein und es wird dann beim Booten automatisch geladen.

Nun ja, das zeigt, dass Du das Konzept von Modulen nicht verstanden hast. Module sollten nicht beim Booten geladen werden (sonst koennte man sie auch gleich fest in den Kernel einbauen), sondern bei Bedarf. Das geschieht ueber modprobe, wenn der Kernel entsprechende Anforderungen stellt, und die Konfigurationsdatei fuer modprobe ist nun einmal bei Kernel 2.2/2.4 die Datei /etc/modules.conf (bei Kernel 2.6 ist es /etc/modprobe.conf). Deswegen wird es dort eingetragen. Wer es in ein Startskript eintraegt oder das Modul beim Booten zwingend laden laesst, macht wohl etwas falsch...

...

Ist das bei SuSE anders?

Du kannst auch bei SuSE (zumindest bei der 8.2, die ich hier habe, bei der 7.x Version kenne ich mich nicht aus) einen Eintrag in /etc/sysconfig/kernel machen, und zwar bei der Variablen MODULES_LOADED_ON_BOOT. Wie David hier aber schon sehr oft geschrieben hat, ist das eigentlich der falsche Weg. Der richtige Weg geht ueber die Datei /etc/modules.conf und dem Laden des Moduls bei Bedarf. Fuer Details, siehe Archiv dieser Liste (einfach mal nach "ide-scsi" und "David Haller" suchen, das sollte reichen :-) CU, Th.

David Haller

03:23

Hallo, Am Sun, 04 Jan 2004, Thomas Hertweck schrieb:

...

Tobias Weisserth wrote: [quotemardernd] [>>Thomas Hertweck:]

...
...
Du solltest die Datei /etc/modules.conf anpassen, dass bei Bedarf das Modul automatisch geladen wird. Finde heraus, welches Device Dein Modem verwendet - Du brauchst die Major und Minor Number. Das ... ... automatisch geladen werden, sobald auf das Device mit der eingetragenen Major/Minor Nummer zugegriffen wird.

Ist das wirklich so kompliziert? Ich weiß ja nicht genau, wie das bei SuSE der Fall ist, aber ich trage ein Modul, das der Kernel automatisch laden soll, einfach in /etc/modules.autoload.d/kernel-[kernel version] ein und es wird dann beim Booten automatisch geladen.

Nun ja, das zeigt, dass Du das Konzept von Modulen nicht verstanden hast.

Jup. Wo auch immer /etc/modules.autoload.d/kernel-[kernel version] verwendet wird, es ist flasch. Den Rest des Rant's hat Thomas mir dankenswerterweise schon abgenommen.

...

Module sollten nicht beim Booten geladen werden (sonst koennte man sie auch gleich fest in den Kernel einbauen), sondern bei Bedarf.

[Ausnahme: die Module die zum booten in die initrd muessen. Und wer mit nem eigenen Kernel ne initrd braucht macht was flscha[tm]). [..]

...

Wer es in ein Startskript eintraegt oder das Modul beim Booten zwingend laden laesst, macht wohl etwas falsch...

s/wohl// Amen!

...

...
Ist das bei SuSE anders?

Du kannst auch bei SuSE (zumindest bei der 8.2, die ich hier habe, bei der 7.x Version kenne ich mich nicht aus) einen Eintrag in /etc/sysconfig/kernel machen, und zwar bei der Variablen MODULES_LOADED_ON_BOOT. Wie David hier aber schon sehr oft geschrieben hat, ist das eigentlich der falsche Weg.

JA! :)

...

Der richtige Weg geht ueber die Datei /etc/modules.conf und dem Laden des Moduls bei Bedarf. Fuer Details, siehe Archiv dieser Liste (einfach mal nach "ide-scsi" und "David Haller" suchen, das sollte reichen :-)

Ne, dazu hab ich zuviel dazu geschrieben, das ist schon zu unspezifisch :) Da muss man das Datum eingrenzen oder z.B. noch 'modules.conf' als Suchbegriff verwenden... Ein "site:lists.suse.com" sowieso. Ein Test: q=+ide-scsi+%22David%20Haller%22+site%3Alists.suse.com -> 452 Treffer q=+ide-scsi+modules.conf+%22David%20Haller%22+site%3Alists.suse.com -> 103 Treffer Beides jew. mit einem 'http://www.google.com/search?hl=de&' davor. -dnh, heute mal ganz unbescheiden ;-)) PS: bei der Suche werden natuerlich auch Antworten auf meine Antworten gefunden ;) -- If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. -- RfC 3514

Tobias Weisserth

13:58

Hallo, nur ganz kurz, weil ich eigentlich schon drauf eingegangen bin: Am Son, den 04.01.2004 schrieb David Haller um 04:23:

...

Jup. Wo auch immer /etc/modules.autoload.d/kernel-[kernel version] verwendet wird, es ist flasch. Den Rest des Rant's hat Thomas mir dankenswerterweise schon abgenommen.

Diese Verfahrensweise ist der Standard bei Gentoo und anderen Distributionen. Ich denke daher nicht, dass es grundlegend falsch ist, Module derart zu verwalten. Es mag falsch sein, die durch SuSE geschaffene Ordnung zu verändern und derart auf einem SuSE System zu verfahren, aber deswegen habe ich die Unterschiede zu SuSE erfragt. Grüße, Tobias

Philipp Thomas

16:16

David Haller [20040104 04:23]:

...

[Ausnahme: die Module die zum booten in die initrd muessen. Und wer mit nem eigenen Kernel ne initrd braucht macht was flscha[tm]).

Nicht unbedingt, er kann auch einfach faul sein :) Ich z.B. ersetze nur vesafb durch matroxfb, alles andere bleibt wie gehabt.

...

...
Wer es in ein Startskript eintraegt oder das Modul beim Booten zwingend laden laesst, macht wohl etwas falsch...

Nicht unbedingt. Philipp

David Haller

21:47

Hallo, Am Sun, 04 Jan 2004, Philipp Thomas schrieb:

...

David Haller [20040104 04:23]:

...
[Ausnahme: die Module die zum booten in die initrd muessen. Und wer mit nem eigenen Kernel ne initrd braucht macht was flscha[tm]).

Nicht unbedingt, er kann auch einfach faul sein :) Ich z.B. ersetze nur vesafb durch matroxfb, alles andere bleibt wie gehabt.

Warum packst du matroxfb nicht wie ich fest in den Kernel? Laeuft hier so seit... # grep '^[^#]*MATROX' /boot/2.2.14c/.config CONFIG_FB_MATROX=y CONFIG_FB_MATROX_MYSTIQUE=y # ls -l /boot/2.2.14c/.config [..] Feb 29 2000 /boot/2.2.14c/.config bald 4 Jahren so. Und soo oft wechselst du ja wohl nicht die Grafikkarte, oder?

...

...
...
Wer es in ein Startskript eintraegt oder das Modul beim Booten zwingend laden laesst, macht wohl etwas falsch...

Nicht unbedingt.

Beispiel? Ich kenne naemlich keins ;) -dnh --

...

Nun ja, die Wand, welche Wohn- und Schlafzimmer trennt, wurde mal komplett mit Spiegeln ausgekleidet. Ich glaub, das taete nicht gut... Ih, dann mußt Du ja ständig sehen, wie Deine Freundin mit so einem häßlichen Kerl im Bett liegt. [Herbert Taeubler und Bernd Brodesser in suse-talk]

Philipp Thomas

5 Jan 5 Jan

01:28

David Haller [So, 4 Jan 2004 22:47:35 +0100]:

...

Warum packst du matroxfb nicht wie ich fest in den Kernel? Laeuft hier so seit...

Latürnich ist matroxfb fest im Kernel (zumindest im 2.4'er, matroxfb im 2.6'er mag meine Optionen für Bildschirmgeometrie nicht). Aber der Rest bleibt eben wie er ist und wandert nicht auch fest in den Kernel.

...

...
Nicht unbedingt.

Beispiel? Ich kenne naemlich keins ;)

ppa/imm auf SCSI-System? OK, dem könnte man mit above/below begegnen, wie mit ide-scsi. Mist, also habe ich auch kein Beispiel zur Hand. Aber mir fällt bestimmt noch eins ein :) Philipp

David Haller

04:00

Hallo, Am Mon, 05 Jan 2004, Philipp Thomas schrieb:

...

David Haller [So, 4 Jan 2004 22:47:35 +0100]:

...
Warum packst du matroxfb nicht wie ich fest in den Kernel? Laeuft hier so seit...

Latürnich ist matroxfb fest im Kernel (zumindest im 2.4'er, matroxfb im 2.6'er mag meine Optionen für Bildschirmgeometrie nicht). Aber der Rest bleibt eben wie er ist und wandert nicht auch fest in den Kernel.

Ah, ok. Und was nicht in die initrd muss, dass muss auch nicht in "MODULES_LOADED_ON_BOOT" (oder wie auch immer das auf $DISTRO jew. heisst / implementiert ist) ;)

...

...
...
Nicht unbedingt.

Beispiel? Ich kenne naemlich keins ;)

ppa/imm auf SCSI-System? OK, dem könnte man mit above/below begegnen, wie mit ide-scsi.

Eben. ppa kenn ich allerdings nur vom IDE-System aus. IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1] IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module. Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen, ebenfalls als logische Folgerung... Dass man natuerlich auch zu _faul_ und/oder "unwissend" sein darf, die Distri-Kernelconfig nicht so "weitgehend" aendern zu wollen, dass die initrd ueberfluessig wird, wenn man nen Distrikernel nur geringfuegig aendern will, sei dahingestellt :) Dafuer muss man dann eben damit kaempfen die richtigen initrds erstellen und in den BM einbinden zu muessen, was IMO auch nicht gerade trivial ist[3]. Mit Kernel 2.6 mag's da evtl. ein paar Spezialitaeten geben, aufgrund der abgespeckten Syntax der modprobe.conf.

...

Mist, also habe ich auch kein Beispiel zur Hand.

*harhar*

...

Aber mir fällt bestimmt noch eins ein :)

-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)... [0] also ausschliesslich via initrd + modules.conf [1] ich behaupte uebrigens nicht, dass es einfach waere, sowas als Distributor zu implementieren. Und dass es meines Wissens keine Distri gibt, die das "korrekt"[0] macht[2], scheint dies zu bestaetigen. [2] sind AFAIK mindestens SuSE, RH, Debian und Gentoo, die ein "load after boot" von Modulen machen... [3] ich habe nie ne eigene initrd erstellen muessen, teils wg. der HW, und dann bald wg. nur noch eigenen Kernels... :) -- Journaling erhöht die Stabilität/Konsistenz des Dateisystems nach einem nötigen Filesystem-Check, der ohne Journal ein fremdes Kinderzimmer aufräumen muss ohne zu wissen, wo der Scheiß eigentlich hin soll, während er mit Journal einen Zettel vor der Tür findet, wo die Rotznase ihre Sachen zu finden wünscht. -- Holger Marzen

Adalbert Michelic

06:44

* On Mon, 05 Jan 2004 at 5:00 +0100, David Haller wrote:

...

IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1]

Generalisierungen sind generell flhsch *eg*

...

IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module.

Nein, warum?

...

Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen,

Probierst Du bitte mal / mittels LVM zu verwalten oder auch blos das /-Volume zu verschlüsseln und davon auch zu booten? Ohne initrd.

...

-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)...

Framebuffer-Treiber, der auch wieder mal wieder raus soll, weil er sich u.U. mit was anderem in die Haare kriegt? Oder andere Sachen, die nach dem Booten verfügbar sein sollen, später aber u.U. wieder raus sollen? /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

David Haller

08:11

Hallo, Am Mon, 05 Jan 2004, Adalbert Michelic schrieb:

...

* On Mon, 05 Jan 2004 at 5:00 +0100, David Haller wrote:

...
IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1]

Generalisierungen sind generell flhsch *eg*

Generell ja. *g*

...

...
IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module.

Nein, warum?

Darum. *eg* [Argumente findest du unten und in anderen Mails von mir, wenn du mich ganz lieb bittest kann ich die auch nochmal explizit auffuehren]

...

...
Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen,

Probierst Du bitte mal / mittels LVM zu verwalten oder auch blos das /-Volume zu verschlüsseln und davon auch zu booten? Ohne initrd.

Geht nicht. Zumindest wenn /lib/modules/`uname -r` auf / also auf dem LVM residiert. LVM hatte ich nur mal kurz im Test. Aber bei Bedarf, d.h. bei Zugriff, sollte a) das Modul, da unter /lib/ auf / gespeichert eh fest in den Kernel bzw. in die initrd muessen, und b) das "laden bei Bedarf" ueber einen korrekten Eintrag in der modules.conf zu erschlagen sein. Ein _explizites_ haendisches laden per "modprobe lvm" (oder wie auch immer) in irgendeinem der bootscripte ist _NICHT NOETIG_. Fuer's verschluesseln gilt analoges. Dein Argument das noch uebrig bleibt ist? Kann sein, dass ich missverstaendlich formuliert hatte, den Teil mit der Einschraenkung hast du ja aber geloescht. Ich sach's nochmal deutlicher: Wer von LVM / ner verschluesselten Partition booten will, der muss lvm/loop (+cryptozeug) a) fest in den Kernel, oder b) in die initrd packen Dass b) bei nem eigenen Kernel _fuer eine Maschine_ wenig sinnvoll ist schrieb ich ja schon ;) Aber das ist ja sowieso nur das gleiche Spielchen wie mit ner SCSI-HDD an ${FOO} SCSI-Controller, der via Modul ${foo} angesprochen wird. Das Modul muss a) fest in den Kernel, oder b) in die initrd. etc. bla. s.o.

...

...
-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)...

Framebuffer-Treiber, der auch wieder mal wieder raus soll, weil er sich u.U. mit was anderem in die Haare kriegt?

Ok, das koennte (in der Praxis(!)) eine Ausnahme sein, ja. Gegen solche begruendeten Ausnahmen hab ich auch nix. matroxfb ist aber z.B. sauber programmiert. Da greift also der Nachsatz: wenn z.B. rivafb oder sonstwas so schlecht ist, dass es Konflikte gibt, dann sollte man den Treiber den Entwicklern um die Ohren hauen, oder den Entwicklern dessen, mit dem sich der Treiber in die Haare kriegt. Das hat also nix mit dem Modulkonzept per se zu tun. Achso, fuer "Kernel-" und "Treiber-" Entwickler gelten sowieso andere Regeln, die wollen natuerlich alles ent- und neuladen koennen. Sowas sollte dann aber nicht in "stable"-Kernels auftauchen. Ich habe absolut nix dagegen, dass man fuer Entwicklerkernel auch mal uebelste Hacks und "dirty tricks" anwendet etc. pp.... Das ist aber eben ein anderes Thema.

...

Oder andere Sachen, die nach dem Booten verfügbar sein sollen, später aber u.U. wieder raus sollen?

Dafuer sorgt modprobe. Ich kann problemlos z.B. per 'mount /cdrom' das automatische laden von 'sr_mod + cdrom + scsi_mod + ide-scsi' anstossen, und nach nem 'umount /cdrom' problemlos die (noch nicht automatisch entladenen) Module per 'modprobe sr_mod cdrom ide-scsi scsi_mod' auch wieder entladen... Wo also ist das Problem? -dnh -- 140: Zufall Zufall ist ein Umstand, den weder der Schuldner noch der Gläubiger zu vertreten hat. (Jurist Wolfgang Kopp)

Adalbert Michelic

14:00

* On Mon, 05 Jan 2004 at 9:11 +0100, David Haller wrote:

...

Am Mon, 05 Jan 2004, Adalbert Michelic schrieb:

...
* On Mon, 05 Jan 2004 at 5:00 +0100, David Haller wrote:

...
IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1] [...] IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module.

Nein, warum?

Darum. *eg* [Argumente findest du unten und in anderen Mails von mir, wenn du mich ganz lieb bittest kann ich die auch nochmal explizit auffuehren]

Ich kenne die Mails. Nur lassen sich für alle Begründungen, Gegenbeispiele finden.

...

...
...
Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen,

Probierst Du bitte mal / mittels LVM zu verwalten oder auch blos das /-Volume zu verschlüsseln und davon auch zu booten? Ohne initrd.

Geht nicht. Zumindest wenn /lib/modules/`uname -r` auf / also auf dem LVM residiert. LVM hatte ich nur mal kurz im Test. Aber bei Bedarf, d.h. bei Zugriff, sollte [...] Dein Argument das noch uebrig bleibt ist?

Hint: Die initrd eignet sich nicht nur für Module.

...

Wer von LVM / ner verschluesselten Partition booten will, der muss lvm/loop (+cryptozeug)

a) fest in den Kernel, oder

b) in die initrd packen

Egal, wie LVM oder cryptoloop jetzt vorliegt: a) bevor jemand ein von LVM verwaltetes Volume mountet, sollte jemand andere die entsprechende Volumegroup mittels 'vgchange -a y' aktivieren. b) bevor jemand ein verschlüsseltes Device mountet, sollte bitte das loop-Device mit losetup aufgesetzt werden (inkl. Passworteingabe).

...

...
...
-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)...

Framebuffer-Treiber, der auch wieder mal wieder raus soll, weil er sich u.U. mit was anderem in die Haare kriegt?

Ok, das koennte (in der Praxis(!)) eine Ausnahme sein, ja. Gegen solche begruendeten Ausnahmen hab ich auch nix. matroxfb ist aber z.B. sauber programmiert. Da greift also der Nachsatz: wenn z.B. rivafb oder sonstwas so schlecht ist, dass es Konflikte gibt, dann sollte man den Treiber den Entwicklern um die Ohren hauen, oder den Entwicklern dessen, mit dem sich der Treiber in die Haare kriegt.

Nein. Steuere die gleiche Karte einmal mit matroxfb, einmal mit vesafb (oder wie heisst der?) an. Das knirscht, wenn beide gleichzeitig laufen.

...

...
Oder andere Sachen, die nach dem Booten verfügbar sein sollen, später aber u.U. wieder raus sollen?

Dafuer sorgt modprobe. Ich kann problemlos z.B. per 'mount /cdrom' das automatische laden von 'sr_mod + cdrom + scsi_mod + ide-scsi' anstossen, und nach nem 'umount /cdrom' problemlos die (noch nicht automatisch entladenen) Module per 'modprobe sr_mod cdrom ide-scsi scsi_mod' auch wieder entladen...

Wo also ist das Problem?

Siehe z.B. die Situation oben: / liegt auf einem verschlüsselten Volume. Verschärfend kommt dazu, daß der zum Mounten erforderliche Schlüssel in Binärform z.B. auf einem USB-Stick liegt. usb-storage soll aber trotzdem nicht permanent im Kernel rumhängen, genauso das restliche SCSI-Subsystem nicht. Du kannst jetzt entweder einen kompletten /lib/modules/ehschonwissen-Baum auf der initrd nachbauen, oder das Modul platzsparend per insmod laden. Egal, in beiden Fällen hast Du wieder Module auf der initrd. Oder: wechsle im Betrieb zwischen APM und ACPI. Beides sind Teile, deren Bedarf sich nicht am Kriterien, die in modules.conf festhaltbar sind, festnageln lässt. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at

Philipp Thomas

12:22

Hi David, David Haller [Mo, 5 Jan 2004 05:00:02 +0100]:

...

IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1]

Ein Modul in MODULES_LOADED_ON_BOOT einzutragen ist aber viel einfacher, als eine modules.conf zu korrigieren bzw. zu vervollständigen :)

...

Dafuer muss man dann eben damit kaempfen die richtigen initrds erstellen und in den BM einbinden zu muessen, was IMO auch nicht gerade trivial ist[3].

Also gerade das finde ich nun äusserst simpel :) Ein kleines Skript, dass von 'make install' aufgerufen wird und welches dann nach dem Installieren von Kernel, System.map und Modulen noch mkinitrd mit den richtigen Parametern aufruft. Nur der Eintrag in lilo.conf oder menu.lst muss halt noch händisch erfolgen. Philipp

Tobias Weisserth

4 Jan 4 Jan

13:54

Hallo, Am Son, den 04.01.2004 schrieb Thomas Hertweck um 01:03:

...

Tobias Weisserth wrote:

...
[...]

Wenn Du zitierst, lasse bitte eine Attribution-Line stehen, damit man weiss, wer was hier gesagt hat. Das folgende doppelt gequotete Zitat stammt von Thomas Hertweck (yes, that's me):

Sorry, so besser? ;-)

...

Nun ja, das zeigt, dass Du das Konzept von Modulen nicht verstanden hast. Module sollten nicht beim Booten geladen werden (sonst koennte man sie auch gleich fest in den Kernel einbauen), sondern bei Bedarf.

Naja, das ist mir schon klar. Aber das eine schließt das andere ja nicht aus. Wenn ich beispielsweise Probleme mit USB Massenspeichergeräten habe und alles fest in den Kernel kompiliert habe, dann werde ich es schwer haben herauszufinden, an welchem Teil meine Bemühungen scheitern. Wenn ich aber alles als Modul vorliegen habe, dann ich der Reihe nach alle Module laden und sehen wo es hapert. Und wenn dann alles klappt, spricht doch nichts dagegen die Module beim Starten durch Linux laden zu lassen, oder? Ich sehe den verwerflichen Frevel nicht, wenn ich mir die händische Arbeit beim Starten abnehmen lasse. Wenn ich die Module dann nicht mehr brauche, entferne ich sie aus der Datei und sie werden nicht mehr geladen. Das erspart mir das Neu-Kompilieren vom Kernel und dem Alsa Modul, wenn ich Module entferne oder hinzufüge.

...

Das geschieht ueber modprobe, wenn der Kernel entsprechende Anforderungen stellt, und die Konfigurationsdatei fuer modprobe ist nun einmal bei Kernel 2.2/2.4 die Datei /etc/modules.conf (bei Kernel 2.6 ist es /etc/modprobe.conf).

Nun ja, was modprobe ist, weiss ich schon. Und meine /etc/modules.conf wird durch modules-update verwaltet. Bei mir sieht das in /etc so aus: modules.autoload.d modules.conf modules.conf.old modules.d modules.devfs Unter modules.autoload.d liegt jeweils eine Datei für unterschiedliche Kernels, in die ich Module eintragen kann, die beim Booten geladen werden sollen. Das ist so durch Gentoo vorgesehen. Ich bin mir nicht ganz sicher, aber ich denke Debian verfährt hier ähnlich. Stimmt das? Irgend jemand? :-)

...

Deswegen wird es dort eingetragen. Wer es in ein Startskript eintraegt oder das Modul beim Booten zwingend laden laesst, macht wohl etwas falsch...

Mmh. SuSE scheint anders zu ticken, aber ich würde nicht sagen, dass Distributionen wie Debian oder Gentoo da etwas falsch machen, weil es anders ist. Oder liege ich da falsch? Ich will nicht unhöflich sein, aber einiges klingt etwas von oben herab...

...

...
Ist das bei SuSE anders?

Du kannst auch bei SuSE (zumindest bei der 8.2, die ich hier habe, bei der 7.x Version kenne ich mich nicht aus) einen Eintrag in /etc/sysconfig/kernel machen, und zwar bei der Variablen MODULES_LOADED_ON_BOOT. Wie David hier aber schon sehr oft geschrieben hat, ist das eigentlich der falsche Weg. Der richtige Weg geht ueber die Datei /etc/modules.conf und dem Laden des Moduls bei Bedarf. Fuer Details, siehe Archiv dieser Liste (einfach mal nach "ide-scsi" und "David Haller" suchen, das sollte reichen :-)

Ich denke der Unterschied liegt nur in der Art und Weise, wie /etc/modules.conf verwendet wird. Mein Gentoo System macht nicht direkt Gebrauch von /etc/modules.conf, sondern bedient sich der Unterstruktur unter /etc/modules.autoload.d/kernel-[foo] und Alias Bezeichnungen und überlässt die modules-update die Pflege. Das ist praktisch und funktioniert einwandfrei. Ansonsten sehe ich keinen grundlegenden Unterschied in der _Verwendung_ von Modulen. Grüße, Tobias

Michael Meyer

15:17

*** Tobias Weisserth wrote:

...

Ich denke der Unterschied liegt nur in der Art und Weise, wie /etc/modules.conf verwendet wird. Mein Gentoo System macht nicht direkt Gebrauch von /etc/modules.conf, sondern bedient sich der Unterstruktur unter /etc/modules.autoload.d/kernel-[foo] und Alias Bezeichnungen und überlässt die modules-update die Pflege. Das ist praktisch und funktioniert einwandfrei. Ansonsten sehe ich keinen grundlegenden Unterschied in der _Verwendung_ von Modulen.

doch, dein system macht gebrauch von der /etc/modules.conf. deine /etc/modules.conf wird aus dem inhalt der dateien unter /etc/modules.d generiert. ,----[ man modules-update ] | [...] | modules-update attempts to fix this by generating the configuration | file from seperate files which are located in /etc/modules.d/. | All files in that directory are assembled together to form | /etc/modules.conf. After generation a backup of the old file is put | in /etc/modules.conf.old. `----| /etc/modules.autoload.d/kernel-[foo] wird von modules-update ignoriert. ,----[ man modules.autoload ] | [...] | The /etc/modules.autoload file contains the names of kernel | modules that are to be loaded at boot time, one per line. Arguments | can be given in the same line as the module name. Comments begin | with a `#', and everything on the line after them are ignored. This | file is read by the /etc/init.d/modules initscript, which is | usually linked in the /etc/runlevels/boot directory. `----| alles klar? ich habe _nichts_ in der /etc/modules.autoload.d/kernel-[foo]. micha

David Haller

21:57

Hallo, Am Sun, 04 Jan 2004, Tobias Weisserth schrieb:

...

Am Son, den 04.01.2004 schrieb Thomas Hertweck um 01:03: [..] und alles fest in den Kernel kompiliert habe, dann werde ich es schwer haben herauszufinden, an welchem Teil meine Bemühungen scheitern. Wenn ich aber alles als Modul vorliegen habe, dann ich der Reihe nach alle Module laden und sehen wo es hapert.

Korrekt. Nur: wenn die Dinger in die initrd muessen, dann hilft dir das dann auch nicht. Und was nicht in die initrd muss kann man (meist) getrost als Modul kompilieren.

...

Und wenn dann alles klappt, spricht doch nichts dagegen die Module beim Starten durch Linux laden zu lassen, oder? Ich sehe den verwerflichen Frevel nicht, wenn ich mir die händische Arbeit beim Starten abnehmen lasse.

Es nicht darum, sondern darum, dass du ueberhaupt haendisch laden musst, bzw. die Module in die "autoload" (in welcher Form auch immer) eintragen musst. Das ist schlicht ein Zeichen dafuer, dass die modules.conf nicht richtig konfiguriert ist. Normal und "richtig[tm]" ist, wenn die Module _bei Bedarf_, beim Zugriff auf das jew. Device automatisch geladen werden, also ohne einen expliziten Aufruf von modprobe/insmod auf der shell oder in irgendeinem (boot-)script. [..]

...

Mmh. SuSE scheint anders zu ticken, aber ich würde nicht sagen, dass Distributionen wie Debian oder Gentoo da etwas falsch machen, weil es anders ist. Oder liege ich da falsch?

Ja. *eg* Wie die Distributionen das machen ist irrelevant. _Dass_ die Module beim booten ueber einen expliziten "modprobe" oder "insmod" geladen werden, das ist was "falcsh" ist.

...

Ich will nicht unhöflich sein, aber einiges klingt etwas von oben herab...

Mag sein *eg*. [..]

...

Ansonsten sehe ich keinen grundlegenden Unterschied in der _Verwendung_ von Modulen.

Ja. Leider. Denn das bedeutet, dass die Distri-Tools es nicht im Griff haben, die modules.conf so zu generieren / konfigurieren, dass ein "autoload" beim booten ueberfluessig ist. -dnh -- *So viele schöne Fragezeichen in meinem Kopf* ;-) [Moritz Esser in suse-linux]

Thomas Hertweck

23:11

Tobias Weisserth wrote:

...

Am Son, den 04.01.2004 schrieb Thomas Hertweck um 01:03:

...
Nun ja, das zeigt, dass Du das Konzept von Modulen nicht verstanden hast. Module sollten nicht beim Booten geladen werden (sonst koennte man sie auch gleich fest in den Kernel einbauen), sondern bei Bedarf.

Naja, das ist mir schon klar. Aber das eine schließt das andere ja nicht aus. Wenn ich beispielsweise Probleme mit USB Massenspeichergeräten habe und alles fest in den Kernel kompiliert habe, dann werde ich es schwer haben herauszufinden, an welchem Teil meine Bemühungen scheitern. Wenn ich aber alles als Modul vorliegen habe, dann ich der Reihe nach alle Module laden und sehen wo es hapert. Und wenn dann alles klappt, spricht doch nichts dagegen die Module beim Starten durch Linux laden zu lassen, oder?

Nun, wozu? Lade sie doch bei Bedarf, um das geht es hier doch...

...

Ich sehe den verwerflichen Frevel nicht, wenn ich mir die händische Arbeit beim Starten abnehmen lasse. Wenn ich die Module dann nicht mehr brauche, entferne ich sie aus der Datei und sie werden nicht mehr geladen. Das erspart mir das Neu-Kompilieren vom Kernel und dem Alsa Modul, wenn ich Module entferne oder hinzufüge.

Genau, das ist es doch. Ich habe hier auch viele Module. Sie werden in der Regel dann geladen, wenn sie gebraucht werden. Dazu dient u.a. die Datei /etc/modules.conf. Da muss ich auch keinen Kernel neu compilieren o.ae. Alles, was zum Booten gebraucht wird, kann fest in den Kernel (fuer einen Distributor mag hier aufgrund der Vielzahl der anzutreffenden Systeme allerdings eine initrd sehr hilfreich sein).

...

[...] Ich denke der Unterschied liegt nur in der Art und Weise, wie /etc/modules.conf verwendet wird. Mein Gentoo System macht nicht direkt Gebrauch von /etc/modules.conf, sondern bedient sich der Unterstruktur unter /etc/modules.autoload.d/kernel-[foo] und Alias Bezeichnungen und überlässt die modules-update die Pflege. Das ist praktisch und funktioniert einwandfrei. Ansonsten sehe ich keinen grundlegenden Unterschied in der _Verwendung_ von Modulen.

Dazu hat Michael schon etwas geschrieben. Ich bin zwar auch kein Module-Experte, aber bei Dir liegt IMHO ein kleines Verstaendnisproblem vor. Die einzige Datei, fuer die sich modprobe interessiert, ist /etc/modules.conf. Alles andere ist modprobe egal (es sei denn, es wurde vom Distributor gepatcht oder es wurde explizit eine andere Konfigurationsdatei spezifiziert), und die zusaetzlichen Verzeichnisse, die Du bei Dir auf dem System findest, sind nur da, um Dir vielleicht die Arbeit etwas leichter zu machen durch Deinen Distributor - er uebernimmt quasi fuer Dich das Editieren der /etc/modules.conf. Das kann man bei SuSE auch, in dem man sich den Dateien in /etc/sysconfig/kernel bedient. Wie Distributoren das letztendlich aber umsetzen, mag dann unterschiedlich verlaufen - einige werden es schlicht zum automatischen Ergaenzen der modules.conf verwenden, andere werden Module per Skript o.ae. beim Booten laden. Das ist aber, wie mehrfach erwaehnt, eigentlich nicht noetig. Module kann man i.d.R. dann laden, wenn sie gebraucht werden. Es mag hier Ausnahmen geben, vielleicht treffe ich mal noch eine :-) Und man kann eben die Datei modules.conf auch von Hand pflegen, das ist aber mitunter nicht so einfach, weil man a) die Syntax kennen muss und b) wissen muss, wie wann wo wer auf welche Devices oder Interfaces etc. zugreift. CU, Th.

Tobias Weisserth

5 Jan 5 Jan

00:47

Hallo Thomas, Am Mon, den 05.01.2004 schrieb Thomas Hertweck um 00:11:

...

Tobias Weisserth wrote:

...
Am Son, den 04.01.2004 schrieb Thomas Hertweck um 01:03:

...
Nun ja, das zeigt, dass Du das Konzept von Modulen nicht verstanden hast. Module sollten nicht beim Booten geladen werden (sonst koennte man sie auch gleich fest in den Kernel einbauen), sondern bei Bedarf.

Naja, das ist mir schon klar. Aber das eine schließt das andere ja nicht aus. Wenn ich beispielsweise Probleme mit USB Massenspeichergeräten habe und alles fest in den Kernel kompiliert habe, dann werde ich es schwer haben herauszufinden, an welchem Teil meine Bemühungen scheitern. Wenn ich aber alles als Modul vorliegen habe, dann ich der Reihe nach alle Module laden und sehen wo es hapert. Und wenn dann alles klappt, spricht doch nichts dagegen die Module beim Starten durch Linux laden zu lassen, oder?

Nun, wozu? Lade sie doch bei Bedarf, um das geht es hier doch...

"Bei Bedarf" ist für mich eben während dem Bootvorgang. :-) Die ursprüngliche Frage hieß ähnlich, glaube ich ;-)

...

...
Ich sehe den verwerflichen Frevel nicht, wenn ich mir die händische Arbeit beim Starten abnehmen lasse. Wenn ich die Module dann nicht mehr brauche, entferne ich sie aus der Datei und sie werden nicht mehr geladen. Das erspart mir das Neu-Kompilieren vom Kernel und dem Alsa Modul, wenn ich Module entferne oder hinzufüge.

Genau, das ist es doch. Ich habe hier auch viele Module. Sie werden in der Regel dann geladen, wenn sie gebraucht werden. Dazu dient u.a. die Datei /etc/modules.conf. Da muss ich auch keinen Kernel neu compilieren o.ae. Alles, was zum Booten gebraucht wird, kann fest in den Kernel (fuer einen Distributor mag hier aufgrund der Vielzahl der anzutreffenden Systeme allerdings eine initrd sehr hilfreich sein).

Mmh. Was in der /etc/modules.conf steht wird dann quasi in Echtzeit bei Bedarf und automatisiert nachgeladen, wenn der Kernel das Modul braucht? Oder was meinst Du?

...

...
[...] Ich denke der Unterschied liegt nur in der Art und Weise, wie /etc/modules.conf verwendet wird. Mein Gentoo System macht nicht direkt Gebrauch von /etc/modules.conf, sondern bedient sich der Unterstruktur unter /etc/modules.autoload.d/kernel-[foo] und Alias Bezeichnungen und überlässt die modules-update die Pflege. Das ist praktisch und funktioniert einwandfrei. Ansonsten sehe ich keinen grundlegenden Unterschied in der _Verwendung_ von Modulen.

Dazu hat Michael schon etwas geschrieben. Ich bin zwar auch kein Module-Experte, aber bei Dir liegt IMHO ein kleines Verstaendnisproblem vor. Die einzige Datei, fuer die sich modprobe interessiert, ist /etc/modules.conf. Alles andere ist modprobe egal (es sei denn, es wurde vom Distributor gepatcht oder es wurde explizit eine andere Konfigurationsdatei spezifiziert), und die zusaetzlichen Verzeichnisse, die Du bei Dir auf dem System findest, sind nur da, um Dir vielleicht die Arbeit etwas leichter zu machen durch Deinen Distributor - er uebernimmt quasi fuer Dich das Editieren der /etc/modules.conf. Das kann man bei SuSE auch, in dem man sich den Dateien in /etc/sysconfig/kernel bedient. Wie Distributoren das letztendlich aber umsetzen, mag dann unterschiedlich verlaufen - einige werden es schlicht zum automatischen Ergaenzen der modules.conf verwenden, andere werden Module per Skript o.ae. beim Booten laden. Das ist aber, wie mehrfach erwaehnt, eigentlich nicht noetig. Module kann man i.d.R. dann laden, wenn sie gebraucht werden. Es mag hier Ausnahmen geben, vielleicht treffe ich mal noch eine :-) Und man kann eben die Datei modules.conf auch von Hand pflegen, das ist aber mitunter nicht so einfach, weil man a) die Syntax kennen muss und b) wissen muss, wie wann wo wer auf welche Devices oder Interfaces etc. zugreift.

Ich denke, ich habe einen Verständnisschritt nach vorne gemacht. Aber inwiefern unterscheidet sich denn SuSE dann von beispielsweise Gentoo, bei dem ich "too8139" in /etc/modules.autoload.d/kernel-2.4 eintragen muss, damit ich nach dem Booten mein eth0 interface habe? Gruß, Tobias

David Haller

01:05

Hallo, Am Mon, 05 Jan 2004, Tobias Weisserth schrieb:

...

Mmh. Was in der /etc/modules.conf steht wird dann quasi in Echtzeit bei Bedarf und automatisiert nachgeladen, wenn der Kernel das Modul braucht?

Genau. [..]

...

Ich denke, ich habe einen Verständnisschritt nach vorne gemacht. Aber inwiefern unterscheidet sich denn SuSE dann von beispielsweise Gentoo, bei dem ich "too8139" in /etc/modules.autoload.d/kernel-2.4 eintragen muss, damit ich nach dem Booten mein eth0 interface habe?

Gar nicht. Aber bei beiden Distributionen wirkt ein alias eth0 8139too in der /etc/modules.conf Wunder. -dnh -- If human beings don't keep exercising their lips, he thought, their mouths probably seize up. After a few months' consideration and observation he abandonded this theory in favor of a new one. If they don't keep on exercising their lips, he thought, their brains start working. -- THHGTTG

Thomas Hertweck

09:49

Hallo Tobias, Tobias Weisserth wrote:

...

Am Mon, den 05.01.2004 schrieb Thomas Hertweck um 00:11:

...
[...] Nun, wozu? Lade sie doch bei Bedarf, um das geht es hier doch...

"Bei Bedarf" ist für mich eben während dem Bootvorgang. :-) Die ursprüngliche Frage hieß ähnlich, glaube ich ;-)

Die urspruengliche Frage zielte dahin, das Modul nicht von Hand per modprobe/insmod laden zu muessen - es gibt dafuer mehrere Moeglichkeiten. Das heisst aber eben nicht, dass es zwangsweise beim Booten geschehen muss. Einige der Methoden sind wohl etwas sauberer (dafuer vielleicht etwas aufwaendiger), andere kann man evtl. als etwas unsauberer bezeichnen (und dafuer leichter zu realisieren). Ich sehe, dass wir eben beim Begriff "bei Bedarf" differieren - bei Bedarf heisst bei mir, das Modul wird genau dann geladen, wenn es benoetigt wird, wenn ich also auf ein bestimmtes Device/Interface etc. zugreifen will.

...

[...] Mmh. Was in der /etc/modules.conf steht wird dann quasi in Echtzeit bei Bedarf und automatisiert nachgeladen, wenn der Kernel das Modul braucht? Oder was meinst Du?

Wie David schon schrieb: genau :-) Du kannst eine Aenderung an /etc/modules.conf machen, laesst ein depmod laufen, und danach wird die Aenderung sofort wirksam. Modprobe schaut stets in die Datei, wenn es etwas zu tun gibt. Fuer ein Beispiel, schau Dir vielleicht mal die Email http://marc.theaimsgroup.com/?l=suse-linux&m=106163514632217&w=2 an, das ist ganz lustig...

...

[...] Ich denke, ich habe einen Verständnisschritt nach vorne gemacht. Aber inwiefern unterscheidet sich denn SuSE dann von beispielsweise Gentoo, bei dem ich "too8139" in /etc/modules.autoload.d/kernel-2.4 eintragen muss, damit ich nach dem Booten mein eth0 interface habe?

Wie David auch hier schon schrieb: die wichtige Zeile ist die aus /etc/modules.conf. Vermutlich wird Dein System, wenn es sauber ist, einfach die Zeile "alias eth0 8139too" in der Datei ergaenzt haben. Aber dazu muss ich kein /etc/modules.autoload.d/kernel-2.4 haben, das kann ich auch von Hand machen (oder per YaST, oder...). Wenn Dein System nicht so sauber verfaehrt, dann hat es vielleicht den modprobe-Aufruf fuer 8138too in ein init-Skript verpackt. Aber, wie Du mittlerweile vielleicht gesehen hast, ist das nicht noetig. Die Grundlagen sind doch auf den Linux-Systemen alle die Gleichen, das sollte man sich immer klar machen - wie einzelne Distributionen etwas umsetzen, ist eine andere Geschichte! Gruesse, Thomson

Ralph Müller

4 Jan 4 Jan

10:28

Hallo, *Thomson schrieb:

...

Du solltest die Datei /etc/modules.conf anpassen, dass bei Bedarf das Modul automatisch geladen wird. Finde heraus, welches Device Dein Modem verwendet - Du brauchst die Major und Minor Number. Das [...] alias char-major-4-64 <modul> [...] Suffix) zu ersetzen ist. Entsprechend musst Du die Major und Minor Number anpassen fuer Deinen Fall. Das "char" steht dafuer, dass es [...] Datei ab und fuehre ein "depmod -a" aus. Danach muesste das Modul automatisch geladen werden, sobald auf das Device mit der eingetragenen Major/Minor Nummer zugegriffen wird.

Vielen Dank für die ausführliche Erklärung. Leider klappt es noch nicht ganz. Das Modul wird offenbar immer noch nicht geladen. Sobald wvdial das Modul benötigt ergibt das dieselbe Fehlermeldung wie vorher als das Modul nicht geladen war: "Cannot open /dev/modem: Eingabe-/Ausgabefehler". Trotz vorherigem "depmod -a". Wie gesagt: Wenn ich pctel.o manuall insmodde klappt es wunderbar. $ ls -l /dev/modem /dev/ttyS15 lrwxrwxrwx 1 root root 11 Jan 3 20:43 /dev/modem -> /dev/ttyS15 crw-rw-rw- 1 root uucp 4, 79 Jan 4 01:08 /dev/ttyS15 $ egrep "pctel|serial" /etc/modules.conf alias char-major-4-79 pctel alias char-major-4 serial alias char-major-5 serial alias char-major-240 usb-serial Ob ich die Zeile "alias char-major-4-79 pctel" oberhalb oder unterhalb der Zeile "alias char-major-4 serial" einfüge, scheint keine Rolle zu spielen. -> Fehler. $ grep pctel /lib/modules/2.2.25/modules.dep /lib/modules/2.2.25/misc/pctel.o: Diese Zeile in der modules.dep ist offenbar durch das "depmod -a" hinzugekommen. Woran könnte es noch liegen daß das Modul nicht automatisch geladen wird? Was mache ich falsch? Ralph

David Haller

22:13

Hallo, Am Sun, 04 Jan 2004, Ralph Müller schrieb: [..]

...

$ ls -l /dev/modem /dev/ttyS15 lrwxrwxrwx 1 root root 11 Jan 3 20:43 /dev/modem -> /dev/ttyS15 crw-rw-rw- 1 root uucp 4, 79 Jan 4 01:08 /dev/ttyS15

$ egrep "pctel|serial" /etc/modules.conf alias char-major-4-79 pctel alias char-major-4 serial alias char-major-5 serial alias char-major-240 usb-serial

Ob ich die Zeile "alias char-major-4-79 pctel" oberhalb oder unterhalb der Zeile "alias char-major-4 serial" einfüge, scheint keine Rolle zu spielen. -> Fehler.

Wie "Fehler"?

...

$ grep pctel /lib/modules/2.2.25/modules.dep /lib/modules/2.2.25/misc/pctel.o:

Diese Zeile in der modules.dep ist offenbar durch das "depmod -a" hinzugekommen.

Jep.

...

Woran könnte es noch liegen daß das Modul nicht automatisch geladen wird?

Hm. Ich kenn den Kruscht nicht, aber mach bitte mal folgendes: # modprobe -r pctel serial # lsmod | head # machwas_mit_/dev/ttyS15 # lsmod | head # modprobe -r pctel serial # modprobe -v -k pctel Und schaue bitte, was von obigem in der /var/log/messages auftaucht. -dnh -- 95: PGP-Keysigning-Party Kultiges Zusammensitzen und gemeinsames Murmeln magischer Zahlen. (Gert Döring)

Ralph Müller

5 Jan 5 Jan

20:19

Hallo, *David schrieb:

...

Am Sun, 04 Jan 2004, Ralph Müller schrieb: [..]

...
$ ls -l /dev/modem /dev/ttyS15 lrwxrwxrwx 1 root root 11 Jan 3 20:43 /dev/modem -> /dev/ttyS15 crw-rw-rw- 1 root uucp 4, 79 Jan 4 01:08 /dev/ttyS15

$ egrep "pctel|serial" /etc/modules.conf alias char-major-4-79 pctel alias char-major-4 serial alias char-major-5 serial alias char-major-240 usb-serial

Ob ich die Zeile "alias char-major-4-79 pctel" oberhalb oder unterhalb der Zeile "alias char-major-4 serial" einfüge, scheint keine Rolle zu spielen. -> Fehler.

Wie "Fehler"?

Ich meine die Fehlermeldung, die wvdial offenbar immer dann meldet wenn das Modul nicht geladen ist: "Cannot open /dev/modem: Eingabe-/Ausgabefehler"

...

...
Woran könnte es noch liegen daß das Modul nicht automatisch geladen wird?

Hm. Ich kenn den Kruscht nicht, aber mach bitte mal folgendes:

# modprobe -r pctel serial

(Nichts in /var/log/messages hinzugekommen)

...

# lsmod | head

In der Ausgabe von lsmod ist weit und breit nichts mit pctel zu sehen. Das Module "serial" ist nun weg, wohl wegen dem vorigen "modprobe -r ..". In /var/log/messages ist nichts hinzugekommen.

...

# machwas_mit_/dev/ttyS15

Gebe in einem xterm-Fenster ein harmloses "wvdial" ein. Und wvdial stellt fest: "Cannot open /dev/modem: Eingabe-/Ausgabefehler" In /var/log/messages tauchen die beiden Zeilen auf (gekürzt): "... Serial driver version 4.27 with HUB-6 ..." "... ttyS00 at 0x03f8 (irq=4) is a 16550A" _Meine_ Interpretation an dieser Stelle: Die dumme Nuß "wvdial" lädt das falsche Modul "serial" anstelle des richtigen Moduls "pctel". (Aber wieso eigentlich?) Vielleicht ist meine Interpretation aber auch falsch.

...

# lsmod | head

Und flup - das Modul "serial" ist wieder mittels lsmod zu sehen, aber ...

...

# modprobe -r pctel serial

..das Leben eines Moduls kann ja so kurz sein: nun isses (Modul "serial") wieder weg aus lsmod.

...

# modprobe -v -k pctel

Ahh, jetzt geht's aber so richtig ab hier: Die Ausgabe von "modprobe -v -k pctel" ist "/sbin/insmod -k -q /lib/modules/2.2.25/misc/pctel.o". In /var/log/messages erscheint: "ttyS15 at 0xe800 (irq=10) is a PCtel" Das Modul pctel taucht jetzt in der Ausgabe von lsmod auf. Anschließend findet wvdial auch keinen Grund mehr zu meckern: Einwahl ins Netz funktioniert.

...

Und schaue bitte, was von obigem in der /var/log/messages auftaucht.

Tue alles wenn es etwas mehr Licht ins Dunkel bringt. <Zusatzfrage> Das folgende hat jetzt mit dem oben dargestellten Fehlerbild nichts zu tun: (Kann als eine Zusatzfrage angesehen werden) Das Benutzen des intern-eingebauten Modems ist - wie ich erst jetzt leider mit Erschrecken festgestellt habe - sehr mühsam: Immer wenn das Telefon-/Modemkabel im Rechner (Modem) steckt, dann funktioniert mein Telefon nur bei eingeschaltetem Rechner. Wenn das Kabel zwar in der Wanddose, aber nicht im Rechner steckt, dann funktioniert das Telefon. Wenn das Telefon funktionieren soll, dann muß ich also bei Ausschalten des Rechners auch das Kabel aus dem Rechner ziehen. Da der Rechner nicht immer angeschaltet ist, muß ich wenn ich "ins Internet" möchte deshalb immer erst unter den Tisch krabbeln und das Kabel in den Rechner stecken, was zwar meine Beweglichkeit fördert, aber nicht wirklich eine Dauerlösung sein kann. Das Kabel ist ein 4-adriges, gebrücktes(!) Telefonanschluß- kabel von der Fa. Conrad Elektronik. Hat jemand eine Erklärung für dieses Fehlerbild? </Zusatzfrage> Ralph

Thomas Hertweck

4 Jan 4 Jan

22:52

Ralph Müller wrote:

...

[...] Vielen Dank für die ausführliche Erklärung. Leider klappt es noch nicht ganz. Das Modul wird offenbar immer noch nicht geladen.

Hast Du Dir mal die Seite http://www.peacefulaction.org/sayamindu/pctel.html#AEN417 angeschaut (Punkt 7.2)? Dort wird das Characer Device mit Major 62 verwendet, weiss allerdings momentan nicht warum, denn laut meiner /usr/src/linux/Documentation/devices.txt steht da nur "Allocated for local/experimental use"... Nun ja, probiere es einfach aus. Habe hier schon sehr lange keinen Kernel 2.2 mehr und auch kein Winmodem, daher kann ich leider selbst schlecht testen. CU, Th.

7424

Age (days ago)

7426

Last active (days ago)

List overview

Download

24 comments

7 participants

participants (7)

Adalbert Michelic
David Haller
Michael Meyer
Philipp Thomas
Ralph Müller
Thomas Hertweck
Tobias Weisserth