früher: <Re : "beim booten etwas starten !(ide-scsi)">
hallo David
hi alle
Aus
Steffen Jana schrieb:
1) Wie verwende ich modprobe und insmod richtig (als user und als root)?
Als User kannst Du weder modprobe noch insmod direkt verwenden, das wird nicht funktionieren (waere auch schlimm, wenn ein normaler User selbstaendig Kernelmodule laden und entladen koennte). Als Root kannst Du beide Programme aufrufen und mit beiden Programmen Kernelmodule von Hand laden - modprobe ist dabei vorzuziehen, weil es eben etwas erweiterte Features besitzt gegenueber von insmod. ABER: im Prinzip solltest Du als Root so etwas nicht machen muessen (ausser vielleicht zu Testzwecken); soll heissen, auf einem ordentlich konfigurierten System DARF es NICHT noetig sein, modprobe oder insmod als Root von Hand aufzurufen, noch darf es noetig sein, dass ein Administrator einen modprobe/ insmod-Befehl in die Datei /etc/init.d/boot.local schreibt. Ich denke, das ist, was David ausdruecken wollte. Auf einem ordentlich konfigurierten System (und die Konfiguration der Module erfolgt i.d.R. ueber /etc/modules.conf) geht das Laden von Modulen automa{t|g}isch. Sobald der Kernel ein Event registriert, fuer das er selbst keine Unterstuetzung hat, sei es nun die Unterstuetzung fuer ein Filesystem oder die Unterstuetzung fuer den Zugriff auf ein Device, dann wird kmod (der Kernel Module Loader) aufgeweckt und fuehrt einen modprobe-Befehl(*) aus, um ein Modul fuer die entsprechende Unterstuetzung zu laden. Das Modul wird registriert und der Kernel kann dann normal mit seiner "Arbeit" fortfahren, zumindest, wenn eben ein entsprechendes Modul erfolgreich geladen werden konnte. Ansonsten wird eine Fehlermeldung ausgegeben... (*)Es wird durch kmod das Programm ausgefuehrt, was die Ausgabe von "cat /proc/sys/kernel/modprobe" ergibt. In der Regel ist das /sbin/modprobe. Bleibt die Frage, wie herausgefunden wird, welches Modul eigent- lich geladen werden soll, wenn o.a. Fall auftritt. Da gibt es verschiedene Moeglichkeiten: o Beim Zugriff auf z.B. ein Device mit der Major Nummer N wird versucht, ein Modul mit dem Namen block-major-N bzw. char-major-N zu laden. Entsprechend findest Du dazu Eintraege in /etc/modules.conf, z.B. "alias char-major-21 sg". Das be- deutet, beim Zugriff auf ein Character Device mit der Major Nummer 21 wird das Modul "sg" durch kmod angefordert, denn char-major-21 ist ein Alias fuer sg. o Beim Zugriff auf ein Netzwerkinterface, das bisher von keinem Treiber registriert wurde, wird schlicht ein Modul angefragt, das den Namen des Interfaces traegt. Bei eth0 wird also ver- sucht, ein Modul mit Namen eth0 zu laden. In der Datei /etc/modules.conf findest Du deswegen z.B. einen Eintrag wie "alias eth0 ne2k-pci" - das bedeutet, letztendlich wird ver- sucht werden, das Modul ne2k-pci, das fuer meine Netzwerkkarte gebraucht wird, zu laden, denn eth0 ist schlicht ein Alias (sprich: anderer Name) fuer ne2k-pc . Bei Dir wird das sicher anders aussehen (ausser Du hast eine Netzwerkkarte, die den gleichen Treiber braucht). o Beim Zugriff auf ein Socket in einer Protokollfamilie, fuer das es bisher keinen Treiber gibt, wird das Modul net-pf-N angefor- dert, wobei N die Nummer der Protokollfamilie ist. Beispiel: "alias net-pf-5 appletalk". o Der ATA Device-Treiber (ide) laedt z.B. die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape oder ide-scsi. Ein "alias <name> off" in /etc/modules.conf besagt uebrigens, das jegliche Anfrage des Kernels, ein derartiges Modul zu laden, ignoriert wird. By the way: es kann passieren, dass ein richtiges Modul geladen wird, obwohl kein entsprechender Eintrag in /etc/modules.conf vorhanden ist. Das erscheint erst einmal seltsam. Das liegt daran, dass modprobe ansich bereits ein paar Aliase fest einprogrammiert hat. Also in dieser Hinsicht nicht wundern.
2) Bei mir ergibt
Jana:~ # ls -l /sbin/modprobe -rwxr-xr-x 1 root root 27863 2003-09-23 19:31 /sbin/modprobe Jana:~ # ls -l /sbin/insmod -rwxr-xr-x 1 root root 9311 2003-09-23 19:31 /sbin/insmod Jana:~ #
Das ist OK.
Und wenn ich eine Verknüpfung für modprobe mit insmod veranlassen will, dann wird mir gesagt, dass modprobe schon existiert.
Mach' das NICHT!
Bedeutet das, das ich (als root) /sbin/modprobe löschen soll, um einen Link /sbin/modprobe zu erstellen, der auf insmod verweist?
NEIN. Der Kernel Module Loader braucht zwingend /sbin/modprobe. Erklaerung siehe oben.
Und heißt das auch, das ich die Rechte entsprechend ändern soll?
NEIN.
3) Oder kommt das alles ganz anders auf die Reihe?
Hmm, ja. Solange Du die /etc/modules.conf richtig administrierst und die korrekten Eintraege dort hast, sollte es nicht noetig sein, irgendetwas als Root von Hand zu machen oder sonst etwas am System zu Hacken. Welche Eintraege in /etc/modules.conf zu machen sind, hat David beschrieben. Ein "depmod -a" sollte immer aufgerufen werden, um die Abhaengigkeiten der Module neu zu bestimmen nach Aenderungen an /etc/modules.conf. HTH, Th.
Thomas Hertweck schrieb:
Steffen Jana schrieb:
1) Wie verwende ich modprobe und insmod richtig (als user und als root)?
[ . . . ] hallo Thomas, herzlichen Dank nochmals für Deine Ausführungen. Auch Dank für die Schnelligkeit. Wirklich Klasse. Einerseits konnte ich das, was Du geschrieben hast, gut verstehen, andererseits hatte ich mir einiges genauso vorgestellt, war aber verunsichert. Nun brauche ich mir doch wenigstens keine Sorgen machen, dass bei mir womöglich Dinge nicht in Ordnung sind. Schöne Grüße Steffen
Thomas Hertweck schrieb:
[...] o Beim Zugriff auf z.B. ein Device mit der Major Nummer N wird versucht, ein Modul mit dem Namen block-major-N bzw. char-major-N zu laden. Entsprechend findest Du dazu Eintraege in /etc/modules.conf, z.B. "alias char-major-21 sg". Das be- deutet, beim Zugriff auf ein Character Device mit der Major Nummer 21 wird das Modul "sg" durch kmod angefordert, denn char-major-21 ist ein Alias fuer sg.
Ich muss mich selbst korrigieren, das war unsauber formuliert: Durch den Kernel wird ueber kmod natuerlich das Modul char-major-21 angefordert. Erst modprobe setzt dann den Namen char-major-21 auf- grund des Aliases in /etc/modules.conf in das Laden des Modules "sg" um. Durch den Kernel werden i.d.R. immer Module mit einem verallge- meinerten Namen angefordert, die dann ueber die Datei modules.conf in tatsaechlich zu ladende (physikalisch vorhandene) Module umge- setzt werden. Deswegen eben die ganzen Aliase in modules.conf bei SuSE. Bei anderen Distris mag diese Datei bedeutend leerer sein, da muss man dann - wenn man eben Module bevorzugt - mal Hand anlegen und ein paar Eintraege vornehmen. Gruesse, Th.
Hallo, [erstmal danke, Thomas, fuer die Unterstuetzung :)] Am Mon, 10 Nov 2003, Thomas Hertweck schrieb:
o Der ATA Device-Treiber (ide) laedt z.B. die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape oder ide-scsi.
Andersrum, die "funktionsspezifischen" Treiber, wie 'ide-cd', 'sr_mod', 'ide-floppy', 'ide-tape', 'st' usw. greifen dann auf das "Basis-Modul" zu, also 'ide' bzw. 'scsi_mod' in diesen Beispielen. Und bei 'ide-scsi' ist das flasch, denn 'ide-scsi' ist ein SCSI-"Controller"-Treiber, genau wie 'aic7xxx' oder so. 'ide-scsi' bekommt also (AFAIK) von 'sg' oder 'sr_mod' via 'scsi_mod' SCSI-Befehle, "uebersetzt" diese Befehle dann nach ATAPI[1] und schickt dann (mit Hilfe von 'ide') die entsprechenden ATAPI Befehle ueber den IDE-Bus an den IDE-Controller bzw. das IDE-Geraet.
By the way: es kann passieren, dass ein richtiges Modul geladen wird, obwohl kein entsprechender Eintrag in /etc/modules.conf vorhanden ist. Das erscheint erst einmal seltsam. Das liegt daran, dass modprobe ansich bereits ein paar Aliase fest einprogrammiert hat. Also in dieser Hinsicht nicht wundern.
Bzw. viele Abhaengigkeiten kann auch depmod aufloesen, die stehen dann in /lib/modules/`uname -r`/modules.dep. Z.B. die Abhaengigkeit von 'sr_mod' -> 'scsi_mod'... -dnh PS: AFAIR hat sich bei Kernel 2.6.x auch nichts grundlegendes geaendert. [1] wobei ATAPI ein nur minimal angepasster SCSI Befehlssatz ist, zu uebersetzen gibt's da also recht wenig, was AFAIR auch der Hauptgrund war, warum cdrecord et al bis jetzt[2] nur SCSI "sprach", d.h. dass also ide-scsi verwendet werden musste. [2] Kernel 2.6.x und ein aktuelles cdrecord -- I'm broken. Please show this to someone who can fix can fix -- A message in a TeX system (Kudos to H J Haataja for the sig)
Guten Morgen! David Haller wrote:
Am Mon, 10 Nov 2003, Thomas Hertweck schrieb:
o Der ATA Device-Treiber (ide) laedt z.B. die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape oder ide-scsi.
Andersrum, die "funktionsspezifischen" Treiber, wie 'ide-cd', 'sr_mod', 'ide-floppy', 'ide-tape', 'st' usw. greifen dann auf das "Basis-Modul" zu, also 'ide' bzw. 'scsi_mod' in diesen Beispielen.
Bist Du sicher? IDE ist AFAIK fest im Kernel, und das sorgt IMHO letztendlich dafuer, dass beim Zugriff auf einen bestimmten Geraetetyp ein entsprechendes Modul geladen wird, nicht umgekehrt. Was Du meinst, ist, dass der komplette Stack einfach geladen wird, wenn z.B. ide-tape benoetigt wird, oder? Hmm...
Und bei 'ide-scsi' ist das flasch, denn 'ide-scsi' ist ein SCSI-"Controller"-Treiber, genau wie 'aic7xxx' oder so.
'ide-scsi' bekommt also (AFAIK) von 'sg' oder 'sr_mod' via 'scsi_mod' SCSI-Befehle, "uebersetzt" diese Befehle dann nach ATAPI[1] und schickt dann (mit Hilfe von 'ide') die entsprechenden ATAPI Befehle ueber den IDE-Bus an den IDE-Controller bzw. das IDE-Geraet.
Auch da wieder die Frage: bist Du sicher? ide-scsi ist leider so ein Zwischending. Einerseits ist es mit SCSI verknuepft, andererseits natuerlich auch mit IDE, denn letztendlich ist das Laufwerk ja immer noch am IDE- Controller angeschlossen und wird ueber die IDE-Schnitt- stelle betrieben. Nur weil nach ide-scsi ein Laufwerk ueber eine SCSI-Geraetedatei angesprochen wird, macht es das IMHO nicht sofort zu einem SCSI-Treiber. Auch nach dem Laden von usb-storage wird das zugehoerige Geraet ueber eine SCSI-Geraetedatei angesprochen, und doch gehoert usb-storage zu USB...
PS: AFAIR hat sich bei Kernel 2.6.x auch nichts grundlegendes geaendert.
Kommt drauf an, was Du unter "grundlegend" verstehst? ;-) Der Kernel-interne Module Loader wurde reimplementiert. Module tragen das Suffix .ko statt .o. Man braucht auf alle Faelle neue modutils, sonst wird das nicht gehen. Und evtl. auch ein neues mkinitrd. Von internen Sachen im Module- Handling jetzt mal abgesehen. Gruesse, Th.
Hallo, Am Tue, 11 Nov 2003, Thomas Hertweck schrieb:
David Haller wrote:
Am Mon, 10 Nov 2003, Thomas Hertweck schrieb:
o Der ATA Device-Treiber (ide) laedt z.B. die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape oder ide-scsi.
Andersrum, die "funktionsspezifischen" Treiber, wie 'ide-cd', 'sr_mod', 'ide-floppy', 'ide-tape', 'st' usw. greifen dann auf das "Basis-Modul" zu, also 'ide' bzw. 'scsi_mod' in diesen Beispielen.
Bist Du sicher?
Weitgehend.
IDE ist AFAIK fest im Kernel,
Ja und? Geht auch als Modul. Das heisst dann 'ide.o' und muesste natuerlich in die initrd wenn man von einem IDE-device booten will. Waere die Verbreitung IDE vs. SCSI genau umgekehrt wuerde SuSE sicher SCSI fest in den Kernel einbauen und ide als Module auslagern (samt den HW-Treibern)... Haengt halt immer davon ab, von was man booten will.
und das sorgt IMHO letztendlich dafuer, dass beim Zugriff auf einen bestimmten Geraetetyp ein entsprechendes Modul geladen wird, nicht umgekehrt.
Jein. IDE ist ein Sonderfall, weil es ueber die gleichen devices / major+minor devices laeuft. Aus ide.c: ==== static int ide_open (struct inode * inode, struct file * filp) { ide_drive_t *drive; int rc; if ((drive = get_info_ptr(inode->i_rdev)) == NULL) return -ENXIO; MOD_INC_USE_COUNT; if (drive->driver == NULL) ide_driver_module(); #ifdef CONFIG_KMOD if (drive->driver == NULL) { if (drive->media == ide_disk) (void) request_module("ide-disk"); if (drive->media == ide_cdrom) (void) request_module("ide-cd"); if (drive->media == ide_tape) (void) request_module("ide-tape"); if (drive->media == ide_floppy) (void) request_module("ide-floppy"); } #endif /* CONFIG_KMOD */ ====
Was Du meinst, ist, dass der komplette Stack einfach geladen wird, wenn z.B. ide-tape benoetigt wird, oder? Hmm...
Jein, s.o. Ich denke das laeuft so ab: Request auf /dev/hdX -> ide.o schaut nach, welcher Treiber dazu noetig ist -> ide-cd macht seine Arbeit und verwendet dabei die Routinen aus 'ide.o' um z.B. den Controller anzusprechen. Also gewissermassen sowas: /-> ide-disk.o -\ /dev/hd* -> ide.o[W] -+--> ide-cd.o ----+--> ide.o[K] +--> piix.o : : : \-> ide-tape.o -/ ide.o[W] := Weichenfunktion in ide.o (also wohl (nur?) ide_open) ide.o[K] := Kernfunktionen in ide.o, z.B. ide_do_request, ide_end_request u.a. piix.o steht hier stellvertretend fuer andere moegliche IDE-Controller Module (z.B. ali14xx, amd74xx, hpt34xx, pdc202xx, via82cxxx, ...). Bei SCSI ist das eben besser aufgeteilt, da gibt's eigene devices (sd*, sr*, st* usw.), daher ist dort keine "Weichenfunktion" noetig.
Und bei 'ide-scsi' ist das flasch, denn 'ide-scsi' ist ein SCSI-"Controller"-Treiber, genau wie 'aic7xxx' oder so.
'ide-scsi' bekommt also (AFAIK) von 'sg' oder 'sr_mod' via 'scsi_mod' SCSI-Befehle, "uebersetzt" diese Befehle dann nach ATAPI[1] und schickt dann (mit Hilfe von 'ide') die entsprechenden ATAPI Befehle ueber den IDE-Bus an den IDE-Controller bzw. das IDE-Geraet.
Auch da wieder die Frage: bist Du sicher?
Weitgehend.
ide-scsi ist leider so ein Zwischending. [..] Nur weil nach ide-scsi ein Laufwerk ueber eine SCSI-Geraetedatei angesprochen wird, macht es das IMHO nicht sofort zu einem SCSI-Treiber.
Doch, ide-scsi emuliert einen SCSI-Adapter Treiber. Schau doch einfach nur mal, wo ide-scsi in /proc/ auftaucht, naemlich dort und so wie z.B. g_NCR5380 oder aic7xxx. Dass ide-scsi im Gegensatz zu z.B. aic7xxx fast nix machen muss, sondern die Befehle mehr oder weniger uebersetzt nur an ide.o weiterreicht steht auf nem anderen Blatt ;) sr_mod -> scsi_mod -> aic7xxx -> HARDWARE sr_mod -> scsi_mod -> ide-scsi -> ide -> piix -> HARDWARE ide-cd -> ide -> piix -> HARDWARE cdrom.o hab ich mal der Uebersicht halber weggelassen.
Auch nach dem Laden von usb-storage wird das zugehoerige Geraet ueber eine SCSI-Geraetedatei angesprochen, und doch gehoert usb-storage zu USB...
Jein. AFAIK, bei ner HDD (bzw. einem als HDD angesprochem Geraet, Kartenleser z.B.): sd_mod -> scsi_mod -> usb-storage -> usb -> .... -> HARDWARE usb-storage macht im Prinzip das gleiche wie ide-scsi, nur eben fuer USB statt IDE.
PS: AFAIR hat sich bei Kernel 2.6.x auch nichts grundlegendes geaendert.
Kommt drauf an, was Du unter "grundlegend" verstehst? ;-) Der Kernel-interne Module Loader wurde reimplementiert. Module tragen das Suffix .ko statt .o. Man braucht auf alle Faelle neue modutils, sonst wird das nicht gehen. Und evtl. auch ein neues mkinitrd. Von internen Sachen im Module- Handling jetzt mal abgesehen.
Das hab ich nicht gemeint, sondern die oben skizzierte Struktur unter den Modulen. Obiges ist der Stand von 2.4.16, d.h. wie jetzt umgebaut wurde weiss ich nicht genau, sieht aber nicht so aus: /newsw3/kernel/linux-2.6.0-test9/drivers/ide $ ls -AF Kconfig ide-default.c ide-iops.c ide-tape.c legacy/ Makefile ide-disk.c ide-lib.c ide-taskfile.c pci/ arm/ ide-dma.c ide-pnp.c ide-tcq.c ppc/ ide-cd.c ide-floppy.c ide-probe.c ide-timing.h setup-pci.c ide-cd.h ide-io.c ide-proc.c ide.c Die Funktionalitaet scheint aber besser aufgeteilt zu sein ;) Und es gibt 'ide_register_driver' / 'ide_unregister_driver' und die Weiche scheint in 'ata_attach' zu sein (und ide_open ist "weg"). Auf die "Treiber-Hierarchie" hat das aber wohl keinen Einfluss. Es laeuft immer noch via /dev/hd* und dann ueber die "Weiche"... /newsw3/kernel/linux-2.6.0-test9/drivers/ide $ grep EXPORT_SYM ide.c ide-io*.c | sed 's/.*(\([^)]*\)).*/\1/' | while read pat; do echo "==== $pat ===="; grep -l "$pat" ide-cd.c ide-disk.c ide-floppy.c ide-tape.c ; done Das ergibt ne Liste, die obige "Theorie" zu bestaetigen scheint. ;) Und dreht man's um: /newsw3/kernel/linux-2.6.0-test9/drivers/ide $ grep EXPORT_SYM ide-cd.c ide-disk.c ide-floppy.c ide-tape.c | sed 's/.*(\([^)]*\)).*/\1/' | while read pat; do echo "==== $pat ===="; grep -l "$pat" ide.c ide-io*.c ide-lib.c ide-dma.c ide-pnp.c ide-probe.c ide-taskfile.c ide-tcq.c ide-timing.h ; done ==== __ide_do_rw_disk ==== ==== __ide_do_rw_disk ==== Ergibt sich nur das Symbol '__ide_do_rw_disk', das aber von ide.c usw. nicht verwendet wird... Ein /newsw3/kernel/linux-2.6.0-test9/drivers/ide $ grep -- "->[^ ]*driver" ide.c ide-io*.c ide-lib.c ide-dma.c ide-pnp.c ide-probe.c ide-taskfile.c ide-tcq.c ide-timing.c scheint das ebenfalls zu bestaetigen (da wird (in ide.c) soweit ich sehe "einfach" nur die Zuordnung Laufwerk->Treiber gemacht, damit ide.o dann die "Weichenfunktion" tatsaechlich wahrnehmen kann). Zuerst (beim booten / init) wird natuerlich geschaut, welches Geraet ueber welchen (IDE-)Treiber angesprochen werden soll. HTH, -dnh -- ... at least I thought I was dancing, 'til somebody stepped on my hand. -- J. B. White
David Haller schrieb:
[...] Request auf /dev/hdX -> ide.o schaut nach, welcher Treiber dazu noetig ist -> ide-cd macht seine Arbeit und verwendet dabei die Routinen aus 'ide.o' um z.B. den Controller anzusprechen.
Also gewissermassen sowas:
/-> ide-disk.o -\ /dev/hd* -> ide.o[W] -+--> ide-cd.o ----+--> ide.o[K] +--> piix.o : : : \-> ide-tape.o -/
ide.o[W] := Weichenfunktion in ide.o (also wohl (nur?) ide_open) ide.o[K] := Kernfunktionen in ide.o, z.B. ide_do_request, ide_end_request u.a.
piix.o steht hier stellvertretend fuer andere moegliche IDE-Controller Module (z.B. ali14xx, amd74xx, hpt34xx, pdc202xx, via82cxxx, ...).
Hmm, das ist doch genau das, was ich urspruenglich sagte, da hast Du aber widersprochen... Ich zitiere nochmal: "Der ATA Device-Treiber (ide) laedt z.B. die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape oder ide-scsi." OK, bei ide-scsi mag das anders sein, da muesste ich in den Code schauen, aber dazu fehlt mir momentan die Zeit. Ich bin mir nicht sicher, ob da nicht doch der IDE-Treiber eine Rolle spielt beim Laden, oder ob das nur ueber SCSI geht. Mein Hinweis, dass IDE fest im Kernel ist, diente nur darauf aufmerksam zu machen, dass es kein ide.o bei lsmod geben wird. Im Prinzip entspricht Deine Skizze aber genau meiner Aussage, deswegen verwirrst Du mich...
[...] sr_mod -> scsi_mod -> aic7xxx -> HARDWARE sr_mod -> scsi_mod -> ide-scsi -> ide -> piix -> HARDWARE ide-cd -> ide -> piix -> HARDWARE
Auch bei dieser Skizze scheint die Vorgehensweise genau meiner Aussage (siehe oben) zu entsprechen. So ganz verstehe ich nicht, auf was fuer ein Problem bzw. Widerspruch Du mich eigentlich aufmerksam machen wolltest... Gruesse, Th. *verwirrt*
Hallo, Am Mon, 10 Nov 2003, Steffen Jana schrieb:
Aus
habe ich - wenn auch verspätet - folgende Angaben kopiert: - - - s n i p p - - - Date: Fri, 24 Oct 2003 02:32:54 +0200 From: David Haller
Subject: Re: beim booten etwas starten! (ide-scsi) Message-ID: <20031024003254.GA6183@feersum.endjinn.de>
Haettest du nicht einfach auf diese Mail antworten koennen?
[ . . . . ] Gugge mal, wie das hier laeuft. In meiner fstab steht u.a.: ==== /dev/cdrom /cdrom iso9660 ro,noauto,noexec,user ==== [ . . . .] ==== root@slarty # ls -l /sbin/modprobe /sbin/insmod -r-x------ 1 root root 112215 Jun 7 2001 /sbin/insmod lrwxrwxrwx 1 root root 6 Mar 21 2002 /sbin/modprobe -> insmod [ . . .] Beachte die Rechte von insmod!
Als !root DARFST du NIE, NICHT UND NIEMALS modprobe verwenden koennen!!! [..] Im Administrationshandbuch zum `Umgang mit Modulen' (Seite 265) habe ich noch u.a. gelesen:
insmod [ . . .] Zugunsten von modprobe sollte insmod nicht mehr verwendet werden.
Aehm, ich muss eigentlich sagen: man sollte weder insmod noch modprobe verwenden ;) Prinzipiell ist das aber richtig, wenn, dann sollte man modprobe verwenden. Und zwar NIE als user.
Wenn auch nicht gesagt ist, ob das im Handbuch auch für root gilt, . . ich krieg das nicht auf die Reihe (weil ich keine Ahnung davon habe).
Was bekommst du nicht auf die Reihe?
Vielleicht kann mir hier ja aber jemand wieder aus dem Irrgarten heraushelfen. (oder wo kann ich das selbst nachlesen?)
man modprobe, man modules.conf?
Hier meine Fragen noch einmal im Detail:
1) Wie verwende ich modprobe und insmod richtig (als user und als root)?
Als user gar nicht. Als root nur 'modprobe <modulname>'. Bei korrekter Konfiguration der modules.conf ist das aber nicht noetig.
2) Bei mir ergibt Jana:~ # ls -l /sbin/modprobe -rwxr-xr-x 1 root root 27863 2003-09-23 19:31 /sbin/modprobe Jana:~ # ls -l /sbin/insmod -rwxr-xr-x 1 root root 9311 2003-09-23 19:31 /sbin/insmod Jana:~ #
Hm. Was sagt ein 'file /sbin/modprobe /sbin/insmod'? Ist evtl. modprobe "not stripped"?
Und wenn ich eine Verknüpfung für modprobe mit insmod veranlassen will, dann wird mir gesagt, dass modprobe schon existiert.
Lass das mal lieber. Ich hab mir meine modutils selbstkompiliert (von SuSE gab's damals keine Pakete), und da kann man bei der Konfiguration angeben, dass nur "ein" binary erzeugt werden soll, welches dann (per hard- oder symlink) auf die anderen verlinkt wird. In der anderen Konfiguration werden "einzelne" binaries fuer jeden Befehl erstellt. Was gibt denn bei dir der folgende Befehl (als root) aus? ls -li /sbin/*mod* | sort -n Bei mir, mit (wie erwaehnt) nur einem binary ist das folgendes: 113604 -r-x------ 1 root root 70213 Jun 7 2001 /sbin/depmod 113613 -r-x------ 1 root root 112215 Jun 7 2001 /sbin/insmod 113614 -r-x------ 1 root root 57089 Jun 7 2001 /sbin/modinfo 113617 lrwxrwxrwx 1 root root 6 Mar 21 2002 /sbin/lsmod -> insmod 113618 lrwxrwxrwx 1 root root 6 Mar 21 2002 /sbin/modprobe -> insmod 113619 lrwxrwxrwx 1 root root 6 Mar 21 2002 /sbin/rmmod -> insmod Da muessen dann aber auch die Rechte von /sbin stimmen(!). Statt der symlinks koennen das auch hardlinks sein, das saehe dann etwa so aus: 113604 -r-x------ 1 root root 70213 Jun 7 2001 /sbin/depmod 113613 -r-x------ 4 root root 112215 Jun 7 2001 /sbin/insmod 113613 -r-x------ 4 root root 112215 Jun 7 2001 /sbin/lsmod 113613 -r-x------ 4 root root 112215 Jun 7 2001 /sbin/modprobe 113613 -r-x------ 4 root root 112215 Jun 7 2001 /sbin/rmmod 113614 -r-x------ 1 root root 57089 Jun 7 2001 /sbin/modinfo (man achte auf die erste und dritte Spalte) Falls bei dir beides nicht der Fall ist (also weder sym- noch hardlinks), dann sind bei dir die Programme wohl einzeln kompiliert. Bei SuSE 8.2 sieht das z.B. so aus: # ls -li /SuSE82/sbin/*mod* | sort -n | grep -v 'old\|static' 6059 -rwxr-xr-x 1 root root 10787 Mar 14 2003 /SuSE82/sbin/usbmodules 6080 -rwxr-xr-x 1 root root 21865 Mar 14 2003 /SuSE82/sbin/depmod 6082 -rwxr-xr-x 1 root root 7729 Mar 14 2003 /SuSE82/sbin/generate-modprobe.conf 6084 -rwxr-xr-x 1 root root 8507 Mar 14 2003 /SuSE82/sbin/insmod 6088 -rwxr-xr-x 1 root root 359 Mar 14 2003 /SuSE82/sbin/insmod_ksymoops_clean 6094 -rwxr-xr-x 1 root root 8562 Mar 14 2003 /SuSE82/sbin/lsmod 6097 -rwxr-xr-x 1 root root 49736 Mar 14 2003 /SuSE82/sbin/modinfo 6098 -rwxr-xr-x 1 root root 23598 Mar 14 2003 /SuSE82/sbin/modprobe 6101 -rwxr-xr-x 1 root root 11583 Mar 14 2003 /SuSE82/sbin/rmmod 6137 -rwxr-xr-x 1 root root 24982 Mar 14 2003 /SuSE82/sbin/modify_resolvconf Die Programme sind offenbar einzeln kompiliert und ausserdem sind die Rechte recht freizuegig gesetzt. In diesem Fall sollte man bei 'depmod', 'insmod', 'modprobe' und 'rmmod' die Rechte strikter setzen (chmod 0500), bei 'lsmod' und 'modinfo' kann man evtl. etwas freizuegiger sein, z.B. chown root.trusted /sbin/modinfo; chmod 0750 /sbin/modinfo verwenden. Was 'usbmodules' ist weiss ich nicht (hab kein USB und bin grad zu faul zum nachschauen) ;)
Bedeutet das, das ich (als root) /sbin/modprobe löschen soll, um einen Link /sbin/modprobe zu erstellen, der auf insmod verweist?
Nein!
Und heißt das auch, das ich die Rechte entsprechend ändern soll?
Ja.
3) Oder kommt das alles ganz anders auf die Reihe?
Was denn?
Für jede Hilfe beim Dazulernen dankbar
Nochmal, wenn die modules.conf richtig konfiguriert ist, dann muss man 'modprobe' nicht in irgendwelchen Bootscripten und erst richt "per Hand" und schon gar nicht als user aufrufen. Wie ich ja schon demonstriert habe, kann ich, mit einer korrekten modules.conf z.B. module laden, ohne jede Rechte an insmod/modprobe. Hier nochmal ein besonders deutliches Beispiel anhand von jstest: ==== root@host # lsmod bttv 66640 1 (autoclean) [.. mehr v4l module sowie soundmodule ..] dh@host $ /usr/local/bin/jstest /dev/js0 Joystick (Analog 2-axis 4-button joystick) has 2 axes and 4 buttons. Driver version is 2.1.0 [..] root@host # lsmod Module Size Used by analog 7776 0 (autoclean) (unused) joydev 7200 0 (autoclean) ns558 2336 0 (autoclean) (unused) gameport 1888 0 (autoclean) [analog ns558] input 3584 0 (autoclean) [analog joydev] bttv 66640 1 (autoclean) [.. die gleichen v4l / sound module wie oben ..] root@host # ls -l /sbin/insmod /sbin/modprobe -r-x------ 1 root trusted 112215 Jun 7 2001 /sbin/insmod lrwxrwxrwx 1 root root 6 Mar 21 2002 /sbin/modprobe -> insmod root@host # ls -l /dev/js0 /dev/input/js0 crw-rw-r-- 1 root root 13, 0 Jun 6 2001 /dev/input/js0 lrwxrwxrwx 1 root root 9 Mar 21 2002 /dev/js0 -> input/js0 root@host # ls -l `which jstest` -rwxr-xr-x 1 dh dh 6412 Mar 21 2003 /usr/local/bin/jstest root@host # egrep '^[^#]*(joy|analog|ns5)' /etc/modules.conf-`uname -r` above input joydev ns558 above joydev analog options analog js=243,none,none,none options mad16 io=0x530 irq=7 dma=0 dma16=1 mpu_io=0x330 mpu_irq=11 joystick=1 ==== Man beachte die Rechte von insmod, jstest und von /dev/input/js0! Die modules.conf ist da wohl noch nicht "ideal", funktioniert aber ;) -dnh -- Paranoid schizophrenics outnumber their enemies at least two to one. -- from the fortune file
participants (3)
-
David Haller
-
Steffen Jana
-
Thomas Hertweck