Voir les modules noyau Linux réellement chargés

Un pilote Wi-Fi, un disque USB ou une carte graphique se comporte mal et vous voulez savoir ce que le noyau a réellement chargé. lsmod répond vite à cette première question. La commande liste les modules actuellement en mémoire, mais elle ne prouve ni que le périphérique fonctionne, ni qu’un module peut être retiré sans conséquence.

Le bon enchaînement consiste à lire la liste, identifier le module, vérifier ses informations avec modinfo, puis regarder les messages du noyau avant de toucher à quoi que ce soit.

Manchot Linux examinant des modules matériels sur une carte mère avec une loupe — Avant de retirer un module, vérifiez ce qu’il pilote et ce que signalent les logs noyau.

Lire lsmod sans se tromper de colonne

Lancez simplement la commande :

lsmod

Chaque ligne donne le nom du module, sa taille, puis le nombre de références. Une valeur non nulle dans Used by indique qu’un autre module s’appuie sur lui. Ce n’est pas un diagnostic matériel. Un module peut être chargé alors que le périphérique est absent, désactivé dans le BIOS ou en erreur.

Pour chercher un pilote précis, filtrez sur son nom. Le ^ évite de mélanger un nom proche avec le module recherché :

lsmod | grep '^nouveaub'
lsmod | grep '^btusbb'

Si la commande ne renvoie rien, deux cas restent possibles : le pilote n’est pas chargé, ou la fonction est intégrée directement au noyau. Les composants compilés en dur ne figurent pas dans lsmod.

Relier un module à son pilote

Utilisez modinfo pour connaître le fichier, la licence, les alias matériels et les dépendances déclarées :

modinfo nouveau
modinfo -F filename nouveau
modinfo -F depends nouveau

Sur certains noyaux, modinfo peut répondre (builtin). Cela confirme justement que le composant n’est pas un module chargeable. Inutile de chercher à le retirer avec modprobe -r.

Avant toute action, comparez aussi le nom remonté par le matériel. Pour un périphérique USB, le guide pour identifier un appareil USB sous Linux permet de vérifier que l’équipement apparaît bien sur le bus. Pour charger un pilote manuellement ou comprendre les dépendances, consultez aussi notre méthode avec modprobe.

Contrôler les logs avant de retirer un module

Quand un pilote est présent mais que le matériel ne répond pas, les journaux noyau donnent souvent la cause. Sur une machine utilisant systemd, commencez par :

journalctl -k -b --no-pager
journalctl -k -b | grep -iE 'nouveau|firmware|error|fail'

Faites cette vérification après avoir branché le périphérique ou reproduit le problème. Une erreur de firmware, une réinitialisation de bus ou un refus du périphérique vaut plus qu’une ligne lsmod isolée.

Vous pouvez préparer un retrait sans l’exécuter avec modprobe -n -v -r nom_module. Si vous envisagez réellement modprobe -r, gardez une seconde session SSH ouverte et ne retirez jamais le pilote réseau, disque ou stockage utilisé par votre connexion. Un module sans dépendance visible peut encore être nécessaire au service en cours.

Vérifier ce qui a changé

Relancez lsmod, contrôlez les logs et testez l’usage réel du périphérique. Pour un réseau, vérifiez l’interface et la connectivité. Pour un disque, confirmez sa présence avec lsblk. Pour une carte graphique, regardez le pilote utilisé avant de lancer une application lourde.

lsmod est un excellent point de départ. Il devient utile quand vous le croisez avec le matériel, modinfo et les logs, pas quand vous supprimez un module parce que son nom vous semble inutile.