LinuxPedia

Wiki libre et indépendant dédié à GNU-Linux et BSD.

Outils pour utilisateurs

Outils du site


commande:modules

Les modules noyaux

Souvent appelés “pilotes”, les modules noyaux sont en général chargés d'interfacer un matériel avec le noyau Linux. Ils sont au cœur du système mais on les ignore la plupart du temps, jusqu'à ce qu'un problème survienne…

<note>Un signe $ précède les commandes qui ne nécessitent pas de droits administrateur ; un signe # précède celles qui nécessitent des droits administrateur (ces signes ne font PAS partie des commandes). Les lignes qui ne commencent pas par un signe $ ou # correspondent au résultat de la commande précédente.
Les touches utilisées sont indiquées entre crochets, exemple [ctrl] pour la touche “contrôle”</note>

Ces modules peuvent exister sous deux formes, soit ils ont été compilé au sein même du noyau, on dit parfois compilé “en dur”, soit ils ont été compilé sous forme de modules externes qui sont stockés sous “/lib/modules/”, organisés en sous répertoires par catégories. Un exemple avec le sous répertoire des modules liés au système son pour l'interface usb (la notation “$(uname -r)” fait porter la commande sur le noyau en cours d'utilisation) :

$ ls -lR /lib/modules/$(uname -r)/kernel/sound/usb
/lib/modules/2.6.30-vanilla64/kernel/sound/usb:
total 184
drwxr-xr-x 2 root root   4096 mai 24 01:16 caiaq
-rw-r--r-- 1 root root 143464 mai 24 01:13 snd-usb-audio.ko
-rw-r--r-- 1 root root  26712 mai 24 01:13 snd-usb-lib.ko
drwxr-xr-x 2 root root   4096 mai 24 01:16 usx2y

/lib/modules/2.6.30-vanilla64/kernel/sound/usb/caiaq:
total 40
-rw-r--r-- 1 root root 37952 mai 24 01:13 snd-usb-caiaq.ko

/lib/modules/2.6.30-vanilla64/kernel/sound/usb/usx2y:
total 68
-rw-r--r-- 1 root root 26160 mai 24 01:13 snd-usb-us122l.ko
-rw-r--r-- 1 root root 39064 mai 24 01:13 snd-usb-usx2y.ko
[...]

Si ça ressemble à du charabia c'est sans doute que vous n'avez jamais eu de problèmes de son avec un micro ou une webcam usb, sinon le nom du module “Alsa” “snd-usb-audio.ko” au moins vous serait familier. Les modules sur un noyau de la famille “2.6” ont donc l'extension “.ko”, même si on peut généralement omettre l'extension lorsqu'on les manipule.

Typiquement vous devrez vous intéresser aux modules si un matériel ne fonctionne pas correctement, si vous venez de brancher un nouveau matériel et voulez vérifier qu'il soit pris en charge. Nous allons voir ici les commandes qui permettent d'interagir avec ces modules comme “lsmod”, “modprobe”, “insmod” ou “rmmod”, et quelques fichiers de configuration qui s'y rapportent.

Quels modules ?

Pour savoir quels modules sont chargés à un moment donné sur votre système on utilise la commande “lsmod”, dont voici une partie du résultat possible :

$ lsmod
Module                  Size  Used by
[...]
snd_hda_intel          26424  5                                                            
snd_hda_codec          64928  2 snd_hda_codec_analog,snd_hda_intel                         
snd_pcm_oss            36496  0                                                            
snd_mixer_oss          14656  1 snd_pcm_oss                                                
snd_usb_audio          89248  1                                                            
snd_pcm                79256  5 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_usb_audio      
snd_usb_lib            16384  1 snd_usb_audio                                                                                                          
snd_seq_dummy           2996  0                                                            
snd_hwdep               7864  1 snd_usb_audio                                              
snd_seq_oss            28688  0                                                            
snd_seq_midi            6608  0                                                            
uvcvideo               55452  0                                                            
i2c_i801                9420  0                                                            
snd_rawmidi            22912  2 snd_usb_lib,snd_seq_midi                                   
mac80211              126424  1 rtl8187                                                    
videodev               40480  1 uvcvideo                                                   
v4l1_compat            12532  2 uvcvideo,videodev                                          
rtc_cmos               11256  0                                                            
rtc_core               19668  1 rtc_cmos                                                   
snd_seq_midi_event      7440  2 snd_seq_oss,snd_seq_midi                                   
snd_seq                50032  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event  
v4l2_compat_ioctl32     9632  1 videodev
[...]

La sortie comprend le nom du module, la quantité de mémoire qu'il emploie, le nombre des autres modules qui l'utilisent et enfin le nom de ceux-ci. La sortie de “lsmod” est en fait une “jolie” mise en forme de ce que vous pouvez consulter sous “/proc/modules” :

cat /proc/modules
[...]
snd_hda_intel 26424 5 - Live 0xffffffffa034a000                                                                            
snd_hda_codec 64928 2 snd_hda_codec_analog,snd_hda_intel, Live 0xffffffffa0338000                                          
snd_pcm_oss 36496 0 - Live 0xffffffffa032a000                                                                              
snd_mixer_oss 14656 1 snd_pcm_oss, Live 0xffffffffa0321000                                                                 
snd_usb_audio 89248 1 - Live 0xffffffffa0306000                                                                            
snd_pcm 79256 5 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_usb_audio, Live 0xffffffffa02ed000                             
snd_usb_lib 16384 1 snd_usb_audio, Live 0xffffffffa02e7000                                            
snd_seq_dummy 2996 0 - Live 0xffffffffa02d1000                                                                             
snd_hwdep 7864 1 snd_usb_audio, Live 0xffffffffa02ca000                                                                    
snd_seq_oss 28688 0 - Live 0xffffffffa02bd000                                                                              
snd_seq_midi 6608 0 - Live 0xffffffffa02b6000                                                                              
uvcvideo 55452 0 - Live 0xffffffffa02a3000                                                                                 
i2c_i801 9420 0 - Live 0xffffffffa029b000                                                                                  
snd_rawmidi 22912 2 snd_usb_lib,snd_seq_midi, Live 0xffffffffa0290000                                                      
mac80211 126424 1 rtl8187, Live 0xffffffffa026c000                                                                         
videodev 40480 1 uvcvideo, Live 0xffffffffa025d000                                                                         
v4l1_compat 12532 2 uvcvideo,videodev, Live 0xffffffffa0257000                                                             
rtc_cmos 11256 0 - Live 0xffffffffa024f000                                                                                 
rtc_core 19668 1 rtc_cmos, Live 0xffffffffa0245000                                                                         
snd_seq_midi_event 7440 2 snd_seq_oss,snd_seq_midi, Live 0xffffffffa023e000                                                
snd_seq 50032 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event, Live 0xffffffffa022c000                         
v4l2_compat_ioctl32 9632 1 videodev, Live 0xffffffffa0227000
[...]

Généralement on ne s'intéresse qu'à une partie du résultat de “lsmod”, pour trier la sortie et ne garder que les informations qui concernent le module “uvcvideo” (pilote pour webcam) on utilisera une redirection vers la commande "grep" ou "egrep" :

$ lsmod | grep uvcvideo
uvcvideo               55452  0
videodev               40480  1 uvcvideo
v4l1_compat            12532  2 uvcvideo,videodev

$ lsmod |egrep '(v4l|videodev)'
videodev               40480  1 uvcvideo
v4l1_compat            12532  2 uvcvideo,videodev
v4l2_compat_ioctl32     9632  1 videodev

Pour savoir quels modules sont utilisés par une matériel connecté au système la solution dépend du mode de connexion. Pour un périphérique interne pci on utilisera :

$ lspci -nnv
[...]
01:00.0 VGA compatible controller [0300]: nVidia Corporation G84 [GeForce 8600 GT] [10de:0402] (rev a1) (prog-if 00 [VGA controller])                                                                                                                 
        Subsystem: Giga-byte Technology Device [1458:3458]                                                                 
        Flags: bus master, fast devsel, latency 0, IRQ 16                                                                  
        Memory at fd000000 (32-bit, non-prefetchable) [size=16M]                                                           
        Memory at d0000000 (64-bit, prefetchable) [size=256M]                                                              
        Memory at fa000000 (64-bit, non-prefetchable) [size=32M]                                                           
        I/O ports at cc00 [size=128]                                                                                       
        [virtual] Expansion ROM at fe8e0000 [disabled] [size=128K]                                                         
        Capabilities: <access denied>                                                                                      
        Kernel driver in use: nvidia                                                                                       

02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller [11ab:4364] (rev 12)                                                                                                                      
        Subsystem: ASUSTeK Computer Inc. Device [1043:81f8]                                                                
        Flags: bus master, fast devsel, latency 0, IRQ 28                                                                  
        Memory at fe9fc000 (64-bit, non-prefetchable) [size=16K]                                                           
        I/O ports at d800 [size=256]                                                                                       
        Expansion ROM at fe9c0000 [disabled] [size=128K]                                                                   
        Capabilities: <access denied>                                                                                      
        Kernel driver in use: sky2

03:00.0 SATA controller [0106]: JMicron Technologies, Inc. 20360/20363 Serial ATA Controller [197b:2363] (rev 03) (prog-if 01 [AHCI 1.0])
        Subsystem: ASUSTeK Computer Inc. Device [1043:824f]
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at feafe000 (32-bit, non-prefetchable) [size=8K]
        Expansion ROM at feae0000 [disabled] [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ahci
[...]

De cette manière vous disposez de nombreuses informations sur le périphérique concerné, ainsi que du module actuellement utilisé sur la dernière ligne “Kernel driver in use:”.

Pour des périphériques usb, ou sur d'autres ports, le meilleur programme est sans doute “hwinfo” (à installer séparément si la commande n'est pas présente sur votre système), qui peut d'ailleurs à lui tout seul procurer des informations complètes quelque soit le mode de connexion du périphérique (interne ou externe). Pour un périphérique usb on l'utilisera comme suit :

$ hwinfo --usb

Le problème de “hwinfo” est qu'il produit des rapports très détaillés, trop si on ne s'intéresse qu'au module utilisé. Pour mieux cibler on peut chercher des mots clés comme ici, ou le nom du fabricant du matériel si on le connait (Logitech, Intel, etc…):

$ hwinfo | egrep '(Driver|Model)'
[...]
Model: "Marvell 88E8056 PCI-E Gigabit Ethernet Controller"
  Driver: "sky2"              
  Driver Modules: "sky2"
    Driver Status: sky2 is active
    Driver Activation Cmd: "modprobe sky2"
  Model: "JMicron 20360/20363 AHCI Controller"
  Driver: "ahci"
  Driver Modules: "ahci"
  Driver Info #0:
    Driver Status: ahci is active
    Driver Activation Cmd: "modprobe ahci"
  Model: "nVidia GeForce 8600 GT"
  Driver: "nvidia"
  Driver Modules: "nvidia"
  Driver Info #0:
Model: "WLAN network interface"
  Driver: "rtl8187"
  Driver Modules: "rtl8187"
  Model: "Network Interface"
  Driver: "rtl8187"
  Driver Modules: "rtl8187"
  Model: "Ethernet network interface"
  Driver: "sky2"
  Driver Modules: "sky2"
[...]

“hwinfo” donne de nombreuses indications, le module qui est sensé prendre en charge le matériel, et même parfois la “commande d'activation” (“Driver Activation Cmd:”) dont nous reparlerons plus bas au sujet de “modprobe”.
Pour connaître toutes les catégories couvertes par “hwinfo”, utilisez l'option “--help” :

<code>$ hwinfo --help

Usage: hwinfo [options] Probe for hardware. […]

hw_item is one of:
 all, bios, block, bluetooth, braille, bridge, camera, cdrom, chipcard,
 cpu, disk, dsl, dvb, fingerprint, floppy, framebuffer, gfxcard, hub,
 ide, isapnp, isdn, joystick, keyboard, memory, modem, monitor, mouse,
 netcard, network, partition, pci, pcmcia, pcmcia-ctrl, pppoe, printer,
 scanner, scsi, smp, sound, storage-ctrl, sys, tape, tv, usb, usb-ctrl,
 vbe, wlan, zip

[..]</code>

Pour savoir quels modules sont effectivement compilés et disponibles sur le système, on utilisera la commande “modprobe” avec l'option “-l” (list). Encore une fois on recherchera en général un module particulier, ici un exemple avec les modules liés au pilote de webcamera “gspca” :

$ modprobe -l | grep gspca
kernel/drivers/media/video/gspca/gspca_main.ko
kernel/drivers/media/video/gspca/gspca_conex.ko
kernel/drivers/media/video/gspca/gspca_etoms.ko
kernel/drivers/media/video/gspca/gspca_finepix.ko
kernel/drivers/media/video/gspca/gspca_mars.ko
kernel/drivers/media/video/gspca/gspca_ov519.ko
kernel/drivers/media/video/gspca/gspca_ov534.ko
kernel/drivers/media/video/gspca/gspca_pac207.ko
kernel/drivers/media/video/gspca/gspca_pac7311.ko
kernel/drivers/media/video/gspca/gspca_sonixb.ko
kernel/drivers/media/video/gspca/gspca_sonixj.ko
kernel/drivers/media/video/gspca/gspca_spca500.ko
kernel/drivers/media/video/gspca/gspca_spca501.ko
kernel/drivers/media/video/gspca/gspca_spca505.ko
kernel/drivers/media/video/gspca/gspca_spca506.ko
kernel/drivers/media/video/gspca/gspca_spca508.ko
kernel/drivers/media/video/gspca/gspca_spca561.ko
kernel/drivers/media/video/gspca/gspca_sunplus.ko
kernel/drivers/media/video/gspca/gspca_stk014.ko
kernel/drivers/media/video/gspca/gspca_t613.ko
kernel/drivers/media/video/gspca/gspca_tv8532.ko
kernel/drivers/media/video/gspca/gspca_vc032x.ko
kernel/drivers/media/video/gspca/gspca_zc3xx.ko
kernel/drivers/media/video/gspca/m5602/gspca_m5602.ko
kernel/drivers/media/video/gspca/stv06xx/gspca_stv06xx.ko

Pour savoir quel module est associé à quel matériel, un petit tour par le fichier “/lib/modules/$(uname -r)/modules.alias” peut s'avérer une bonne idée. Ce fichier est assez aride, en fait il liste des correspondances entre des identifiants matériels et le nom du module correspondant :

[...]
alias pci:v000011ABd00004363sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004362sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004361sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004360sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd0000435Asv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004357sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004356sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004355sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004354sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004353sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004352sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004351sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004350sv*sd*bc*sc*i* sky2                       
alias pci:v000011ABd00004347sv*sd*bc*sc*i* sky2
[...]
alias pci:v000011ABd00005040sv*sd*bc*sc*i* sata_mv
alias pci:v000011ABd00006145sv*sd*bc*sc*i* pata_marvell
[...]

Le fichier étant extrêmement long, seule une petite partie a été reproduite ici. La série de lettres et de chiffres qui suivent la mention “pci:” compose un identifiant matériel, le nom en fin de ligne (exemple “sky2”) est le nom du module qui est associé au matériel.

Pour trouver les identifiant du matériel présent sur votre système vous pourrez utiliser “lspci” ou “lsusb” :

$ lspci -nvv
[...]
02:00.0 0200: 11ab:4364 (rev 12)
        Subsystem: 1043:81f8    
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 
        Latency: 0, Cache Line Size: 32 bytes                                                                
        Interrupt: pin A routed to IRQ 28                                                                    
        Region 0: Memory at fe9fc000 (64-bit, non-prefetchable) [size=16K]                                   
        Region 2: I/O ports at d800 [size=256]                                                               
        Expansion ROM at fe9c0000 [disabled] [size=128K]                                                     
        Capabilities: <access denied>                                                                        
        Kernel driver in use: sky2
[...]
$ lsusb
Bus 001 Device 002: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter
[...]

L'identifiant qui nous intéresse est sur la première ligne pour “lspci” (ici “11ab:4364”), et pour “lsusb” la suite alphanumérique suivant “ID” (ici “0bda:8187”). Une recherche avec ces identifiants dans le fichier des alias nous donne :

$ grep -i "11ab.*4364" /lib/modules/$(uname -r)/modules.alias
alias pci:v000011ABd00004364sv*sd*bc*sc*i* sky2

$ grep -i "0bda.*8187" /lib/modules/$(uname -r)/modules.alias
alias usb:v0BDAp8198d*dc*dsc*dp*ic*isc*ip* rtl8187
alias usb:v0BDAp8197d*dc*dsc*dp*ic*isc*ip* rtl8187
alias usb:v0BDAp8189d*dc*dsc*dp*ic*isc*ip* rtl8187
alias usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip* rtl8187

Pour la recherche nous avonc utilisé la commande "grep" avec l'option “-i” pour ignorer la casse. Les symboles “.*” au milieu du motif de recherche signifie “n'importe quel(s) caractère(s) répété(s) zero fois ou plus”. Cela nous permet de construire un motif de recherche qui corresponde à la syntaxe du fichier “modules.alias”.
Ce type de recherche est surtout intéressant si vous avez un matériel très récent, dont l'identifiant ne figure pas dans le fichier, mais dont les caractéristiques techniques sont les mêmes qu'un modèle plus ancien, dont l'identifiant est proche. Cela permet de charger manuellement le bon module pour en tester le fonctionnement, et ensuite d'en assurer le chargement au démarrage.

Manipuler les modules

Les commandes de base sont très simples, pour charger un module précis on pourra utiliser “insmod”, mais cette commande ne gérant pas les dépendances entre modules on lui préfère aujourd'hui “modprobe” :

# modprobe uvcvideo

Par exemple ici nous venons de charger le module “uvcvideo”, et toutes les modules dont il dépend éventuellement seront chargés en même temps.
Pour connaître les dépendances “modprobe” parcourt le fichier “/lib/modules/$(uname -r)/modules.dep”, dont voici un court extrait relatif au module “uvcvideo” :

$ cat /lib/modules/$(uname -r)/modules.dep | grep uvcvideo
kernel/drivers/media/video/uvc/uvcvideo.ko: kernel/drivers/media/video/videodev.ko kernel/drivers/media/video/v4l1-compat.ko kernel/drivers/media/video/v4l2-compat-ioctl32.ko

Au chemin du module lui-même (uvcvideo.ko) succède celui de ses dépendances (videodev.ko, v4l1-compat.ko, v4l2-compat-ioctl32.ko). Cela signifie que si vous souhaitez utiliser “insmod” pour charger manuellement le module “uvcvideo” il faudra auparavant charger les dépendances dans le bon ordre, en espérant qu'elles n'aient pas également des dépendances… Voilà pourquoi on préfère utiliser “modprobe”.
On peut également lister les dépendances d'un module avec l'option “--show-depends” de “modprobe” :

# modprobe --show-depends kvm-intel
insmod /lib/modules/2.6.29.4-vanilla64/kernel/arch/x86/kvm/kvm.ko
insmod /lib/modules/2.6.29.4-vanilla64/kernel/arch/x86/kvm/kvm-intel.ko

Voir “modinfo” également un peu plus bas.

Le fichier “modules.dep” est peuplé par la commande “depmod”, celle-ci est en générale appelée automatiquement lors de l'installation de modules, mais si ce n'est pas le cas (module compilé “à la main”) “modprobe” risque de vous donner une erreur “FATAL: Module xxxx not found”. Dans ce cas il faut manuellement rafraîchir la liste avec :

# depmod -A

L'option “-A” cherche les modules plus récents que le fichier “modules.dep”, pour totalement recréer ce dernier on utilisera l'option “-a”.

Pour décharger un module, on utilisera au choix “rmmod” (pas de gestion des dépendances) ou l'option “-r” de “modprobe” :

# modprobe -r uvcvideo

Le module ne peut pas être déchargé s'il est encore utilisé par d'autres, dans ce cas il faudra les décharger dans le bon ordre. Un exemple avec le module de virtualisation “kvm” :

$ lsmod | grep kvm
kvm_intel              41512  0
kvm                   152272  1 kvm_intel

# modprobe -r kvm
FATAL: Module kvm is in use.

# modprobe -r kvm-intel
$ lsmod | grep kvm

“lsmod” nous montre que le module “kvm” est utilisé par “kvm_intel”, décharger “kvm” échoue donc. En revanche décharger “kvm_intel” qui n'est pas utilisé réussi, et entraîne le déchargement de “kvm”.
On voit dans cet exemple qu'il n'y a pas de différence dans les noms de modules entre le tiret “-” et le tiret bas “_”, on peut écrire “kvm-intel” ou “kvm_intel”, il s'agit du même module.

Fichiers de configuration

Parfois on a besoin de passer des options additionnelles lors du chargement d'un module, le moyen adéquat est de placer un script dans le répertoire “/etc/modprobe.d/”.

Ce répertoire contient différents scripts qui seront exécutés lors d'un appel de “modprobe”, plus des fichiers de configuration comme “aliases”, “blacklist.conf”. Si vous devez passer des options particulières à un module, il y a de fortes chances qu'elles vous aient été suggéré sur un forum, une liste de diffusion, ou un wiki dédié à la question. Ces options sont spécifiques, il en existe un très grand nombre, ça n'avancerait à rien d'en donner certaines en particulier ici, et ça dépasse notre propos. Sachez juste que c'est dans ces scripts que vous devrez mettre le “quirk=machin” pêché sur un wiki de Alsa. Si une telle manipulation est nécesssaire n'oubliez pas de faire un rapport de bug.
Si le module en question n'est pas automatiquement chargé au démarrage, voyez “charger un module au démarrage” plus bas.

Le fichier “blacklist.conf” est particulier, il contient une liste de modules qui ne doivent pas être chargés au démarrage. Par exemple si le module “schmoll.ko” bloque le fonctionnement de votre carte son ou de votre modem (si,si, c'est un cas connu), vous ajouterez :

blacklist schmoll

Le fichier “aliases” ne nécessite normalement aucune modification, il contient la correspondance entre certains modules et le nom d'usage de celui-ci, ainsi que les “device” tels que nommés par udev avec un identifiant majeur et un mineur, et le nom des modules qui leurs correspondent.

Charger un module au démarrage

Si vous avez identifié le module en charge de votre matériel, vous avez testé son fonctionnement en le chargeant avec “modprobe”, il est est maintenant temps d'assurer le chargement de ce module automatiquement au démarrage du système.

La manipulation est simple, mais peut varier en fonction des distributions :

  • Sur Debian et dérivés (Ubuntu etc…) il suffit d'ajouter le nom du module au fichier /etc/modules. Difficile de faire plus simple, si vous voulez charger le module “schmoll” au démarrage il suffit de faire :
# echo "schmoll" >> /etc/modules

Si le module nécessite des paramètres additionnels, il suffit de créer un script qui se nomera “schmoll.conf” dans le répertoire /etc/modprobe.d/ vu précédement.

  • Sur Fedora, le chargement du module sera assuré par un script avec l'extention “.modules” dans le répertoire /etc/sysconfig/modules/. Par exemple pour charger le module “schmoll” vous créerez un script “schmoll.modules” avec le contenu :
#!/bin/sh

exec /sbin/modprobe schmoll

Ce script pourra être beaucoup plus élaboré, contenir des options supplémentaires…
Les curieux constateront qu'il existe des scripts faisant la même chose, à savoir charger des modules, au niveau supérieur du répertoire /etc/sysconfig/. Ces scripts sont exécutés par ceux présents dans les différents niveaux d'exécution (/etc/rc*.d/, liens vers /etc/init.d/). Les modifier n'est pas une bonne idée, les modifications seraient écrasées à la prochaine mise à jour du paquet correspondant.

  • Pour les autres distributions qui n'utilisent aucune de ces deux méthodes, et bien trouvez la solution et venez la partager ici !! ;-)

Cas particulier : les modules nécessaires au démarrage

Si un module est nécessaire au démarrage, par exemple si votre partition système est sur un système raid, ou formatée avec le système de fichier ext4, vous aurez besoin que ces modules soient chargé AVANT que la partition système ne puisse être montée, et donc avant que les fichiers sous /etc puissent être lus.

Il y a deux approches à cette situation :

  • Si le module en question est compilé dans le noyau, et vous n'utilisez pas d'image RAM de démarrage (“initrd”), vous devrez alors avoir une partition “/boot” séparée, utilisant un système de fichier reconnu directement par le chargeur d'amorçage (exemple ext2/3), et contenant l'image du noyau (“vmlinuz”). La même solution peut également s'utiliser pour héberger un “initrd”.
  • Vous utilisez un initrd, vous l'hébergerez sur une partition “/boot” séparée si votre chargeur d'amorçage ne reconnaît pas le format du système de fichier de la partition système. Si le chargeur d'amorçage reconnaît la partition système (grub2), l'initrd peut rester sur celle-ci.

Mais dans tous les cas vous devrez vous assurer que les modules nécessaires font bien partie de l'initrd.
Sur un système Debian on ajoutera les noms des modules nécessaires au fichier “/etc/initramfs-tools/modules”. En suite il faudra mettre à jour l'initrd avec :

# update-initramfs -u

Sur un système Fedora les noms des modules seront ajoutés au fichier “/etc/sysconfig/mkinitrd” (à créer s'il n'existe pas) sous la forme :

MODULES="schmoll raid1 ext4"
pour inclure les modules "schmoll", "raid1" et "ext4". Si les modules doivent être chargés très tôt, ce qui est le cas des modules liés au système de fichier, au raid ou au lvm, utilisez "PREMODS=" avec (ou à la place de) "MODULES=".\\

Ensuite vous devez créer l'initrd avec :

# mkinitrd initrd-$(uname -r).img $(uname -r)

où “initrd-…” sera le nom du nouvel initrd, suivi en deuxième argument de la version de noyau concernée (tel que renvoyé par la commande “uname -r” pour le noyau en cours d'utilisation).

Compiler des modules externes

La plupart des modules sont inclus dans le noyau, et compilés en même temps que celui-ci. Cependant il peut arriver que vous soyez obligé d'utiliser un module dont le code n'est pas inclu dans votre noyau. Si vous avez installé le noyau standard de votre distribution, vérifiez si le module dont vous avez besoin est disponible avec votre gestionnaire de paquet. Si le module est disponible, installer la version qui correspond EXACTEMENT à votre noyau, sinon il ne fonctionnera pas.
Si le module n'est pas disponible sous forme pré-compilée dans votre gestionnaire de paquets, vous devrez télécharger les sources du module, et les compiler vous même. Pour ça vous pouvez vous référer à l'article “compilation”, et surtout au(x) fichier(s) de documentation inclus dans les sources du module (README, INSTALL etc…).
D'une manière générale vous aurez toujours besoin des sources et/ou des en-tête (“headers”) qui correspondent exactement à votre noyau, et des paquets “make” et “gcc”. La procédure de compilation peut varier, en général il s'agit de taper les commandes “make” puis “make install” dans le répertoire des sources du module. Certaines distributions fournissent des procédures spéciales pour vous faciliter le travail (exemple : “module-assistant” sur Debian/Ubuntu). Une fois le module compilé et installé sa manipulation se fera comme pour n'importe quel module (voir “modprobe” et “depmod” plus haut).

Voilà pour les bases, vous devriez pouvoir vous débrouiller avec les modules présent sur votre système.

commande/modules.txt · Dernière modification: 2018/11/17 13:52 (modification externe)