infra / linux-bash
Modules noyau : lsmod, modprobe, insmod
Explication
Ce que vous allez apprendre
- Comprendre que le noyau Linux peut charger du code additionnel à chaud, sans redémarrer
- Lister et inspecter les modules déjà chargés avec
lsmodetmodinfo - Choisir
modprobeplutôt queinsmodgrâce à sa résolution automatique des dépendances - Charger un module automatiquement au démarrage, ou au contraire le bloquer (blacklist)
- Diagnostiquer un module qui refuse de charger avec
dmesg
Dans quel contexte ?
Tu branches un nouveau disque NVMe sur un serveur et lsblk ne le voit pas apparaître. Avant de suspecter un problème matériel, il faut vérifier si le bon module noyau est réellement chargé.
D'abord, une idée à corriger sur le fonctionnement du noyau
On pourrait croire que tout ce dont Linux a besoin (pilotes, systèmes de fichiers, protocoles réseau) est figé une fois pour toutes au démarrage. En réalité, le noyau peut charger du code additionnel à chaud, sous forme de modules, sans redémarrer la machine — c'est ce qui permet de reconnaître un périphérique USB branché en cours de fonctionnement.
Pourquoi ne pas tout inclure directement dans le noyau
Compiler le support de tout le matériel possible directement dans le noyau le rendrait énorme, avec des pilotes inutiles chargés en mémoire pour du matériel absent de ta machine. Les modules permettent de charger uniquement ce qui est réellement nécessaire, comme nvme pour un disque SSD NVMe.
Une fois cette logique comprise, il reste une question pratique : comment charger un module
lsmod liste ce qui est déjà chargé, avec son compteur d'utilisation et ses dépendances. modinfo e1000e montre les informations d'un module précis (description, paramètres) sans avoir besoin de le charger d'abord.
Voici où deux commandes se ressemblent mais diffèrent vraiment
insmod charge un fichier .ko précis mais échoue si ses dépendances ne sont pas déjà en place. modprobe nvme résout automatiquement l'arbre de dépendances avant de charger, ce qui en fait le bon réflexe au quotidien — insmod restant réservé à des cas de debug très ciblés.
| Commande | Résout les dépendances | Usage recommandé |
|---|---|---|
insmod | Non, échoue si dépendance manquante | Debug très ciblé uniquement |
modprobe | Oui, automatiquement | Réflexe au quotidien |
Maintenant, comment rendre ce chargement permanent au démarrage
Ajouter le nom du module dans /etc/modules-load.d/custom.conf le charge automatiquement à chaque boot. À l'inverse, echo "blacklist pcspkr" | sudo tee /etc/modprobe.d/blacklist-pcspkr.conf empêche un module précis de se charger, utile pour désactiver un pilote qui pose problème.
Bon à savoir
Un module ajouté dans /etc/modules-load.d/ n'est chargé qu'au prochain redémarrage. Pour un test immédiat, charge-le d'abord à la main avec modprobe, sans attendre un reboot.
Le piège à connaître
Un module qui refuse de charger affiche rarement une erreur claire dans le terminal : la vraie explication se trouve presque toujours dans dmesg | tail -30, le premier réflexe avant toute autre piste de diagnostic. Maintenant que tu sais gérer le noyau à chaud, la prochaine leçon retrace toute la séquence de démarrage, du bootloader jusqu'au premier processus utilisateur.
Commandes & code
Modules noyau : lsmod, modprobe, insmod
Un module noyau ajoute du code au kernel à chaud (pilote, système de fichiers, protocole réseau) sans recompiler ni redémarrer.
# --- Lister les modules actuellement chargés ---
lsmod # nom, taille, compteur d'utilisation, dépendances
lsmod | grep nvme # filtre sur un module précis
# --- Informations détaillées sur un module (chargé ou non) ---
modinfo e1000e # description, auteur, licence, paramètres acceptés, dépendances
modinfo -F version nvme # extrait un seul champ
modinfo -p kvm # liste uniquement les paramètres configurables du module
# --- Charger un module ---
sudo modprobe nvme # résout et charge aussi les dépendances automatiquement
sudo modprobe nvme debug=1 # avec un paramètre de module
sudo insmod /lib/modules/$(uname -r)/kernel/drivers/nvme/host/nvme.ko # charge un .ko précis, SANS dépendances
# --- Décharger un module ---
sudo modprobe -r nvme # décharge proprement (échoue si le module est utilisé)
sudo rmmod nvme # équivalent bas niveau, pas de résolution de dépendances
# --- Charger un module automatiquement au boot ---
echo "nvme" | sudo tee -a /etc/modules-load.d/custom.conf
sudo tee /etc/modprobe.d/nvme.conf <<'EOF'
options nvme io_queue_depth=1024
EOF
sudo update-initramfs -u # régénère l'initramfs si le module est nécessaire tôt au boot
# --- Empêcher un module de se charger (blacklist) ---
echo "blacklist pcspkr" | sudo tee /etc/modprobe.d/blacklist-pcspkr.conf
sudo modprobe -r pcspkr # décharge s'il est déjà présent
# --- Dépendances entre modules ---
modprobe --show-depends nvme # arbre de dépendances sans charger
cat /lib/modules/$(uname -r)/modules.dep | grep nvme
sudo depmod -a # régénère modules.dep après une installation manuelle de module
# --- Debug d'un module qui refuse de charger ---
dmesg | tail -30 # erreurs noyau les plus récentes (souvent la cause exacte)
sudo modprobe -v nvme # verbose : montre chaque commande insmod exécutée
cat /proc/modules | grep nvme # vue brute équivalente à lsmod
# --- Paramètres d'un module déjà chargé ---
ls /sys/module/nvme/parameters/
cat /sys/module/nvme/parameters/io_queue_depthRésumé
lsmodregarde ce qui est chargé,modprobecharge/décharge EN résolvant les dépendances (préférer àinsmod/rmmod)./etc/modules-load.d/charge un module au boot,/etc/modprobe.d/blacklist-*.confl'empêche de se charger.dmesgreste la première source de vérité quand un module refuse de charger ou plante.
Exercices pratiques
Mission : un disque NVMe invisible après branchement
Objectif : Diagnostiquer et résoudre l'absence d'un module noyau plutôt que de suspecter une panne matérielle.
Contexte
Tu branches un nouveau disque NVMe sur un serveur et lsblk ne le voit pas apparaître. Avant de suspecter une panne matérielle ou de redémarrer la machine, tu dois vérifier si le bon module noyau est réellement chargé.