Table des matières
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 :
# 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.