Un mercredi soir, mise à jour classique du serveur de la maison : dnf update -y, une centaine de paquets dont un nouveau noyau et de nouveaux firmwares, puis reboot. D’habitude, la machine revient en moins d’une minute. Cette fois, rien. Pas de ping, pas de SSH, et surtout aucune réponse ARP sur le réseau local : vu du switch, la carte réseau n’existait plus. Cet article reprend l’enquête dans l’ordre : le symptôme, les traces qu’un arrêt laisse derrière lui, puis le coupable : la carte mère.
En un coup d’œil
| Indice | Ce que j’ai observé | Ce que ça prouve |
|---|---|---|
| Réseau | Ni ping, ni SSH, aucune réponse ARP | Le noyau ne tourne pas, ou la carte réseau n’est pas initialisée |
| Wazuh | Dernier événement « Wazuh agent stopped » à l’heure du reboot | Arrêt propre, pas un crash |
| rsyslog | Le journal s’arrête à « System is rebooting » | Silence normal : rsyslog s’arrête parmi les premiers services |
| wtmp | Entrée shutdown à 19:50:04 | systemd est allé au bout de la séquence d’arrêt |
| Montages XFS | « Ending clean mount » sur les quatre systèmes de fichiers | Tous les disques ont été démontés proprement |
| Conclusion | Trente minutes sans aucune activité | Blocage après l’appel de redémarrage du noyau : carte mère ou firmware |
Le symptôme : une machine muette
Le détail de l’ARP compte. Une machine qui démarre mais dont un service plante répond toujours à l’ARP, car c’est le noyau qui répond, pas une application. L’absence d’ARP signifie que le noyau ne tourne pas, ou que la carte réseau n’est pas initialisée. Le problème est donc bas niveau : démarrage du noyau, initramfs, firmware de la carte mère, ou machine tout simplement éteinte.
Ce qu’on peut vérifier à distance
Avant de descendre devant la machine, j’ai rassemblé ce qui était visible depuis le reste du réseau :
arping -c 3 -I eth0 192.168.10.17 # aucune réponse : la carte réseau est muette
ip neigh show 192.168.10.17 # entrée FAILED dans la table ARP du voisin- Le SIEM (Wazuh) avait reçu un dernier événement de l’agent de la machine : « Wazuh agent stopped », à l’heure exacte du reboot. C’est le signe d’un arrêt propre, pas d’un crash. Un crash n’aurait laissé aucun message.
- Les autres machines du réseau fonctionnaient normalement : le problème ne venait ni du switch ni du routeur.
- La machine virtuelle hébergée sur ce serveur était tombée avec lui, ce qui est cohérent avec un hôte éteint.
Ce qu’il fallait voir à l’écran
Sans carte de gestion à distance (pas d’IPMI sur une carte mère grand public), la seule façon de savoir est de regarder l’écran. Voici la liste que je me suis préparée, de la cause la plus probable à la moins probable, pour ne pas improviser devant la console :
- Bloqué dans GRUB ? Choisir le noyau précédent dans le menu. S’il démarre, le nouveau noyau ou son initramfs sont en cause. On le fixe ensuite avec
grubby --set-default. - Shell d’urgence (dracut, emergency mode) ?
journalctl -xb -p errmontre pourquoi : volume LVM introuvable, entréefstabinvalide, module manquant dans l’initramfs. - Réétiquetage SELinux ou fsck en cours ? C’est long sur un gros disque. Il faut attendre, surtout ne pas couper.
- Démarré mais sans réseau ?
ip -br aetnmcli dev: une carte renommée ou « unmanaged » après une mise à jour arrive plus souvent qu’on ne croit. - Écran noir, ventilateurs qui tournent, rien ne bouge ? C’est le cas le plus déroutant. C’était le mien.
La machine a fini par repartir après une demi-heure, avec un appui long sur le bouton d’alimentation. Le système a démarré normalement sur le nouveau noyau, sans aucune erreur. Restait à comprendre ce qui s’était passé, alors que le journal système ne gardait que le démarrage en cours. C’est l’objet de la section suivante.
Lire les traces d’un arrêt
La machine est revenue, mais journalctl ne montre que le démarrage en cours. Sur ce serveur, le journal n’est pas persistant (Storage=auto sans répertoire /var/log/journal). Les traces du démarrage précédent sont donc perdues de ce côté-là. Heureusement, d’autres sources survivent à un redémarrage.
Source 1 : rsyslog et /var/log/messages
grep -E "System is rebooting|Command line:" /var/log/messages | tail -4
# 19:49:42 systemd-logind: System is rebooting.
# 20:20:22 kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-211.67.1…Le journal s’arrête net à « System is rebooting », puis reprend trente minutes plus tard avec la ligne de commande du nouveau noyau. Ce silence n’est pas suspect : rsyslog fait partie des premiers services arrêtés pendant un reboot, il n’écrit donc jamais la fin de la séquence d’arrêt. Il faut chercher la suite ailleurs.
Source 2 : wtmp, le registre des connexions et des arrêts
last -x -F | head -6
# reboot system boot 6.12.0-211.67.1 Wed Oct 21 20:20:26 2026 still running
# shutdown system down 6.12.0-211.54.1 Wed Oct 21 19:50:04 2026 - 20:20:26 (00:30)last -x affiche aussi les entrées système, pas seulement les connexions. La ligne shutdown system down est écrite par systemd-update-utmp à la toute fin de la séquence d’arrêt, quand presque tous les services sont déjà arrêtés. Sa présence prouve que systemd est allé au bout. Elle est horodatée à 19:50:04, soit 22 secondes après le début du reboot. La colonne « (00:30) » est la durée jusqu’au démarrage suivant : trente minutes pendant lesquelles la machine n’a rien fait.
Source 3 : le montage des systèmes de fichiers au démarrage suivant
grep -E "XFS .*(Mounting|recovery|clean mount)" /var/log/messages | grep "20:20"
# XFS (dm-0): Mounting V5 Filesystem …
# XFS (dm-0): Ending clean mountQuand un système de fichiers XFS n’a pas été démonté proprement, le montage suivant rejoue son journal et affiche « Starting recovery » puis « Ending recovery ». Ici, les quatre systèmes de fichiers indiquent « Ending clean mount » : ils avaient tous été démontés correctement. Le système d’exploitation avait donc terminé son arrêt avant que la machine ne se fige.
Ce que ça permet de conclure
- l’arrêt systemd est allé au bout (entrée
shutdowndans wtmp) ; - les disques ont été démontés proprement (montage « clean » ensuite) ;
- la machine n’a ensuite plus rien fait pendant trente minutes, jusqu’à ce qu’on la relance à la main.
Le blocage s’est donc produit après que le noyau a demandé à la carte mère de redémarrer, quelque part entre cet appel et le BIOS. Ce n’est ni un paquet, ni un service, ni un système de fichiers.
Pour la prochaine fois
Rendre le journal persistant simplifie beaucoup ce genre d’enquête. C’est une ligne :
mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal
journalctl --list-boots # les démarrages précédents apparaissent désormaisMême persistant, le journal ne verra jamais ce qui se passe après l’arrêt du noyau. Les indices de wtmp et des montages restent les plus fiables pour savoir si un arrêt s’est terminé proprement.
Le coupable : la carte mère
Récapitulons les preuves : l’arrêt systemd s’est terminé, les systèmes de fichiers ont été démontés proprement, puis la machine n’a plus rien fait pendant trente minutes. Le coupable se trouve donc entre l’appel de redémarrage du noyau et le premier écran du BIOS. Autrement dit, la carte mère n’a jamais effectué sa réinitialisation.
Comment Linux redémarre une machine
À la fin de l’arrêt, le noyau appelle reboot(), et celui-ci doit déclencher un vrai reset matériel. Sur x86, le noyau essaie plusieurs méthodes, dans un ordre par défaut qui dépend de la machine :
acpi: écrire dans le registre de reset déclaré par le firmware (table ACPI FADT) ;kbd: la méthode historique, une impulsion via le contrôleur clavier ;pci: écrire dans le port 0xCF9, le registre de reset du chipset ;efi: demander au firmware UEFI de redémarrer ;triple: provoquer une « triple faute » du processeur, en dernier recours.
Si la méthode choisie ne fonctionne pas sur une carte précise, le noyau a tout arrêté et attend un reset qui ne vient jamais. C’est exactement le tableau observé : écran noir, ventilateurs qui tournent, plus aucune activité réseau.
Pourquoi cette fois-là, et pas les autres ?
Le redémarrage suivant, sur le nouveau noyau, a pris 34 secondes, sans aucun souci. Plusieurs facteurs ont pu jouer le soir du blocage : l’ancien noyau avec 35 jours d’uptime, et une mise à jour des firmwares (linux-firmware) dans la même transaction. Ces blocages au reset sont connus pour être intermittents sur certaines cartes mères grand public. Je n’ai pas pu reproduire le problème, et je n’ai donc rien changé dans l’immédiat.
Si ça se reproduit
La piste est de forcer une autre méthode de reset avec le paramètre noyau reboot=, puis de tester plusieurs redémarrages :
grubby --update-kernel=ALL --args="reboot=pci" # ou reboot=efi, reboot=acpi
grubby --info=DEFAULT | grep args # vérifier
reboot # tester, plusieurs fois
grubby --update-kernel=ALL --remove-args="reboot" # pour revenir en arrièrereboot=pci (le registre 0xCF9 du chipset) est souvent la plus fiable sur le matériel Intel grand public, et reboot=efi sur les firmwares UEFI récents. Le paramètre s’applique à tous les noyaux installés, y compris les prochains.
Ce que j’en retiens
- avant d’accuser une mise à jour, vérifiez si l’arrêt s’est terminé : wtmp et les montages « clean » le disent sans ambiguïté ;
- un blocage après un arrêt propre relève du matériel ou du firmware, pas du système : aucun retour arrière de paquets ne l’aurait corrigé ;
- rendez le journal persistant (
/var/log/journal) pour que les démarrages précédents restent consultables ; - si la machine héberge un service dont tout dépend, notez la procédure de reprise. Ici, le coffre à secrets doit être descellé à la main après chaque redémarrage : c’est le sujet d’un autre article.
Laisser un commentaire