Dmesg sous Linux : lire les messages du noyau quand un disque ou un périphérique décroche

Un disque USB disparaît, une carte réseau décroche, un SSD répond mal ou une machine affiche une erreur juste après le démarrage ? Avant de modifier la configuration au hasard, je regarde presque toujours les messages du noyau.

Sous Linux, dmesg permet de lire ces messages rapidement. Ce n’est pas un outil magique, mais il donne souvent le premier indice utile : une erreur I/O, un périphérique USB réinitialisé, un firmware manquant, un pilote qui râle ou un lien réseau instable.

Dans ce guide, je vous montre comment utiliser dmesg proprement, le croiser avec journalctl -k, filtrer les lignes utiles et éviter la fausse bonne idée qui consiste à changer une option système avant d’avoir compris le message.

Ce que dmesg affiche vraiment

dmesg affiche le tampon de messages du noyau Linux. En clair, vous y trouvez les événements bas niveau : détection de matériel, pilotes, erreurs disque, USB, réseau, ACPI, firmware, mémoire, montage de périphériques, etc.

Sur une machine récente, une partie de ces messages est aussi visible dans le journal systemd. C’est pour cela que je vous conseille de garder les deux commandes sous la main : dmesg pour une lecture rapide, journalctl -k pour une lecture plus propre dans le journal du système.

dmesg

Sur certaines distributions, la lecture peut demander les droits administrateur. Si vous obtenez une erreur de permission, relancez avec sudo.

sudo dmesg

La page de manuel de dmesg détaille toutes les options. Pour un diagnostic courant, quelques commandes suffisent déjà largement.

Lire les dernières lignes sans se noyer

Le premier réflexe, c’est de ne pas afficher 800 lignes d’un coup. Quand un problème vient juste d’arriver, commencez par la fin du journal noyau.

sudo dmesg -T | tail -n 80

L’option -T rend les dates plus lisibles. Attention, ce format reste pratique pour lire vite, mais il ne remplace pas une analyse complète des journaux si vous comparez des événements très précis. Pour cela, journalctl reste plus confortable.

Vous pouvez aussi afficher seulement les avertissements et les erreurs :

sudo dmesg -T --level=err,warn

Si la commande ne retourne rien, ce n’est pas forcément mauvais signe. Cela veut simplement dire que le noyau n’a pas enregistré d’erreur ou d’avertissement récent dans ce tampon.

Filtrer un problème USB, disque ou réseau

Le vrai gain de temps arrive quand vous filtrez. Si vous cherchez pourquoi une clé USB ne monte pas, pourquoi un disque décroche ou pourquoi une carte réseau se réinitialise, ne lisez pas tout. Cherchez les mots qui correspondent au matériel.

sudo dmesg -T | grep -iE 'usb|sda|sdb|nvme|ata|error|fail|reset'

Pour un disque, les lignes à surveiller sont souvent assez parlantes : I/O error, reset, failed command, blk_update_request, read error, write error. Si vous voyez ce genre de message en boucle, ne commencez pas par réécrire /etc/fstab. Vérifiez d’abord le câble, le boîtier USB, l’alimentation, puis l’état du disque.

Pour un périphérique USB, croisez avec les commandes déjà vues dans le guide sur les ports USB sous Linux ou celui sur le montage d’une clé USB. dmesg vous dit ce que le noyau observe, mais lsusb, lsblk et findmnt aident à comprendre ce qui est réellement détecté et monté.

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
findmnt
lsusb

Pour un souci réseau, cherchez plutôt le nom de l’interface ou des termes comme link, renamed, firmware, timeout, down, up. Si le sujet concerne surtout les ports TCP à l’écoute, basculez plutôt sur ss ou netstat, car dmesg ne remplace pas un inventaire réseau.

Suivre les messages pendant que vous branchez le matériel

Quand un périphérique décroche de manière intermittente, le plus simple est de suivre les messages en direct. Ouvrez un terminal, lancez la commande, puis branchez le disque, la clé USB ou l’adaptateur réseau.

sudo dmesg -wH

-w suit les nouveaux messages. -H rend la sortie plus lisible. Si vous préférez rester dans le journal systemd, utilisez plutôt :

sudo journalctl -k -f

La page de manuel de journalctl est utile si vous voulez affiner par démarrage, priorité ou unité. Pour une panne matérielle simple, le suivi en direct suffit souvent à voir si le noyau détecte le branchement, puis l’erreur.

Croiser avec journalctl pour le dernier démarrage

dmesg est rapide, mais je ne m’arrête pas là si le problème touche un serveur ou revient après reboot. Le journal systemd permet de relire les messages noyau du démarrage courant, avec des filtres propres.

sudo journalctl -k -b --no-pager
sudo journalctl -k -b -p warning..alert --no-pager

La première commande affiche les messages noyau du boot actuel. La seconde garde seulement les avertissements, erreurs et alertes. C’est pratique après un redémarrage où un montage a échoué, où une interface réseau n’est pas montée correctement, ou quand un pilote annonce un problème au boot.

Si vous venez de modifier /etc/fstab, ne redémarrez pas juste pour voir. Testez d’abord le montage et vérifiez les erreurs. Le guide sur fstab sous Linux détaille ce point, parce qu’une mauvaise ligne peut bloquer le démarrage plus vite qu’on ne l’imagine.

sudo mount -a
findmnt
sudo journalctl -k -b -p warning..alert --no-pager

Savoir quand le message indique un vrai problème matériel

Une ligne isolée dans dmesg ne suffit pas toujours à conclure. Un périphérique USB peut se réinitialiser une fois sans que ce soit grave. En revanche, une erreur qui revient à chaque copie, un disque qui alterne déconnexion et reconnexion, ou des erreurs I/O répétées doivent être prises au sérieux.

Dans ce cas, je fais trois vérifications avant de toucher à la configuration :

• changer le câble, le port USB ou l’alimentation si le périphérique est externe ;
• vérifier que le disque est bien identifié avec lsblk et blkid ;
• contrôler l’état SMART si c’est un disque ou un SSD.

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
sudo blkid
sudo smartctl -a /dev/sdX

Remplacez /dev/sdX par le bon disque. Ne copiez pas cette commande à l’aveugle sur une machine avec plusieurs disques. Si vous hésitez, arrêtez-vous à lsblk et identifiez le modèle, la taille et le point de montage avant d’aller plus loin.

Avant de corriger, notez l’erreur exacte

La meilleure utilisation de dmesg, ce n’est pas de trouver une commande miracle. C’est de récupérer une erreur précise avant d’agir. Copiez quelques lignes autour du message, notez l’heure, le périphérique concerné et l’action qui déclenche le problème.

sudo dmesg -T | tail -n 120 > diagnostic-noyau.txt
sudo journalctl -k -b -p warning..alert --no-pager >> diagnostic-noyau.txt

Ensuite seulement, vous pouvez décider : câble à remplacer, disque à sauvegarder, pilote à vérifier, règle fstab à corriger, firmware à installer ou service à regarder. Cette étape paraît basique, mais elle évite pas mal de diagnostics absurdes, surtout sur les pannes intermittentes.

Si vous administrez une machine distante, soyez encore plus prudent. Une erreur disque ou réseau vue dans le noyau peut finir par couper votre accès. Gardez une session ouverte, prévoyez un accès console si possible, et ne redémarrez pas avant d’avoir compris ce que le noyau essaie de vous dire.

sudo apt update && sudo apt upgrade