Mon serveur Linux s’allume mais est injoignable (ni SSH ni ping), est-il mort ?

Pas forcément. S’il démarre (LED d’activité qui clignote puis s’éteint) sans jamais monter le réseau, il est probablement bloqué en mode maintenance/emergency : le fsck de démarrage a trouvé des erreurs sur le rootfs qu’il ne corrige pas automatiquement, et systemd tombe dans un shell d’urgence — qui n’active pas le réseau. La machine attend une saisie que, sur un serveur sans écran, personne ne peut donner.

Pourquoi Linux tombe en emergency mode ou maintenance au démarrage ?

Au boot, systemd-fsck vérifie les filesystems marqués pass ≥ 1 dans /etc/fstab. Si le rootfs porte le flag « erreurs » (typiquement après des arrêts brutaux) et que fsck ne peut pas réparer sans intervention, il retourne un code qui fait entrer systemd dans emergency.target : shell root, pas de réseau, pas de SSH.

Comment réparer un rootfs sur un serveur headless (sans écran ni console série) ?

Sans moyen de répondre au prompt de maintenance, réparez hors-ligne : sortez le disque et branchez-le sur une autre machine via un adaptateur USB-SATA, puis sudo fsck.ext4 -y -f /dev/sdXN. Alternative : booter une clé rescue (SystemRescue, Debian live) et faire le fsck depuis là. Remettez le disque, ça reboote.

Des coupures de courant répétées peuvent-elles empêcher un serveur de démarrer ?

Oui. Chaque arrêt non propre laisse des incohérences ext4 (inodes orphelins, bitmaps de blocs/inodes, compteurs faux). Elles sont bénignes une par une et fsck -y les corrige, mais si le filesystem finit marqué « avec erreurs », le fsck de boot peut refuser de continuer automatiquement et basculer en maintenance.

Serveur qui boote mais injoignable : le `fsck` de boot

Après une série d’arrêts brutaux (alimentation capricieuse), mon serveur headless refuse de revenir. Il s’allume : la LED d’activité clignote deux ou trois minutes… puis s’éteint et plus rien. Pas de SSH, pas de ping, No route to host. Le réflexe est de le croire mort — carte mère, disque, boot cassé.

Il n’était pas mort. Il attendait, dans un shell de maintenance que personne ne pouvait voir.

Le symptôme qui trompe

La séquence « LED d’activité qui clignote puis s’éteint et reste éteinte, sans réseau » est caractéristique : le noyau et l’initrd se chargent (activité disque), puis quelque chose s’arrête et attend au lieu de finir le boot. Sur une machine avec écran, on verrait un prompt. Sur un serveur headless, on ne voit rien — d’où l’impression de matériel HS.

À l’opposé, un vrai plantage matériel ne montre souvent aucune activité disque soutenue.

La cause : le `fsck` de démarrage

Au boot, systemd-fsck passe sur les filesystems marqués pass ≥ 1 dans /etc/fstab — dont le rootfs. Si le rootfs a accumulé des erreurs (les arrêts brutaux : inodes orphelins, bitmaps incohérents) et qu’il est marqué « contient des erreurs », fsck ne les répare pas automatiquement en contexte de boot. Il rend un code d’échec, et systemd bascule dans emergency.target :

You are in emergency mode. After logging in, type "journalctl -xb" ...
Give root password for maintenance (or press Control-D to continue):

Ce shell n’active pas le réseau. Le serveur est « up » (le kernel tourne, il répond parfois encore au ping quelques secondes) mais inerte et injoignable. Combiné à errors=remount-ro dans les options de montage, tout concourt à s’arrêter plutôt qu’à booter sur un fs douteux.

La réparation — hors-ligne

Sans console série ni écran, impossible de répondre au prompt. On répare le disque depuis une autre machine :

# Sortir le disque, le brancher en USB-SATA sur un PC Linux
sudo fsck.ext4 -n -f /dev/sdXN   # d'abord en lecture seule : voir l'ampleur
sudo fsck.ext4 -y -f /dev/sdXN   # puis réparer (répond oui à tout)

Dans mon cas, les erreurs étaient les grands classiques de l’arrêt sale — inodes orphelins, décomptes de blocs/inodes faux — toutes bénignes, corrigées en une passe. Le disque remis en place, la machine a booté normalement.

Si le rootfs est sur un RAID logiciel, l’array se réassemble par UUID sur le PC de secours (mdadm le voit tout seul) et on fsck le /dev/mdX de la même façon.

Prévention et alternatives

Boot rescue plutôt que dépose disque : SystemRescue ou un live Debian, puis fsck du rootfs monté nulle part.
fsck.mode=force / réglage systemd : sur un serveur headless, on peut vouloir un fsck automatique plus agressif au boot pour éviter le mode maintenance — au prix d’une réparation non supervisée.
La vraie prévention, c’est l’alim : ici, les arrêts sales venaient d’une alimentation en fin de vie. Traiter la cause matérielle a supprimé les corruptions à répétition.

Lessons learned

« Boote mais injoignable + LED d’activité qui s’éteint » ≈ souvent un blocage en mode maintenance (fsck), pas un serveur mort.
Le fsck de boot peut halter sur un rootfs marqué « avec erreurs » → emergency.target, sans réseau.
Sur du headless, on ne peut pas répondre au prompt : réparer hors-ligne (dépose disque + fsck sur un autre PC) ou via un boot rescue.
Les arrêts brutaux répétés accumulent des erreurs ext4 — bénignes à l’unité, mais qui finissent par bloquer. La cause est souvent en amont (alim, câblage).