Boot qui échoue : rescue et méthode

Prérequis : cours systemd (DevOps 1.2 + Linux 3.x).

Pourquoi

Un reboot qui ne remonte pas, c'est la panne la plus stressante (pas de SSH, pas de logs habituels). La méthode + la console hors-bande transforment la panique en procédure.

Concepts

• Étapes du boot : firmware/UEFI → bootloader (GRUB) → noyau → initramfs → systemd (targets). Situer l'échec = savoir quoi réparer (GRUB ? fstab ? service ?).
• Modes de secours : emergency shell (système minimal, root, FS en lecture seule), rescue target (réseau + presque tout). Via GRUB (systemd.unit=emergency.target) ou console provider.
• fstab : cause n°1 des boots en emergency (UUID faux, option erronée, FS corrompu). mount -a AVANT tout reboot (cf. 2.3 !) + nofail sur les non-critiques (un disque data ne doit jamais bloquer le boot !).
• Journaux persistants : journalctl -b -1 (boot précédent !) — d'où Storage=persistent, sinon l'échec s'efface au reboot qui suit.

Exemple : fstab fautif en emergency

# shell emergency : FS en ro →
mount -o remount,rw /
nano /etc/fstab      # corriger l'UUID/option
mount -a             # VÉRIFIER avant de rebooter !
systemctl reboot

Cas réel

Ajout d'un disque data en fstab sans nofail, disque débranché au trimestre suivant : 3 reboots en emergency avant de comprendre (le message défilait trop vite). Depuis : nofail sur tout ce qui n'est pas système + photo du fstab avant modif.

Pièges

• quiet qui cache tout : en debug, retirer quiet/splash (GRUB edit temporaire, touche e) pour VOIR où ça bloque.
• Réparer sans monter en rw : edits « sauvegardés » dans le vide (FS ro !). remount,rw d'abord.
• Pas de console hors-bande configurée : la découvrir pendant la panne = trop tard. La tester AVANT (cf. DevOps 8.3).

À retenir

Situer l'étage (GRUB/noyau/fstab/service), fstab testé + nofail, journal persistant, console testée avant.