La chaîne de démarrage Linux pour le dépannage : firmware, chargeur d'amorçage, noyau, initramfs et systemd

Ce que c'est

bootup(7) décrit la chaîne : le firmware du système effectue une initialisation matérielle minimale, puis passe la main à un chargeur d'amorçage (GRUB ou systemd-boot) stocké sur un support persistant. Le chargeur d'amorçage lance un noyau d'OS depuis le disque ou le réseau ; sur les systèmes EFI, le firmware peut aussi charger directement le noyau. Le noyau monte ensuite une racine en mémoire — l'initramfs, une archive CPIO compressée extraite dans un tmpfs — qui localise et monte le véritable système de fichiers racine. L'initramfs transmet alors le contrôle au gestionnaire système de l'hôte (systemd(1) sur la plupart des distributions actuelles), qui détecte le matériel restant, monte les autres systèmes de fichiers et démarre les services configurés jusqu'à la cible par défaut.

Pourquoi c'est important

Une défaillance à l'une de ces étapes se manifeste différemment et appelle une correction différente : un échec du firmware ou du chargeur d'amorçage n'affiche aucune sortie du noyau ; un échec du noyau produit des messages noyau précoces mais pas d'init ; un échec de l'initramfs fait généralement tomber dans un shell précoce ((initramfs) sur Debian/Ubuntu, un shell d'urgence dracut sur la famille RHEL) ou reste bloqué en attente d'un périphérique racine ; un échec de systemd laisse le noyau démarrer normalement, mais des services échouent ou le système se retrouve dans une cible autre que celle par défaut. Considérer ces quatre cas comme un simple « ça ne démarre pas » fait perdre du temps à réinstaller le mauvais composant.

Comment l'appliquer

• Observer la console pendant le démarrage (en local, via le port série ou via la console de l'hyperviseur) pour identifier la dernière étape ayant produit une sortie.
• Une fois qu'un démarrage atteint systemd, consulter le journal propre à ce démarrage : journalctl -b pour le démarrage en cours, journalctl -b -1 pour le précédent si le système a redémarré de lui-même (ajouter --no-pager dans les scripts ; par défaut, la sortie est paginée via less). La lecture du journal système exige les droits root ou l'appartenance à systemd-journal, adm ou wheel.
• Mesurer où systemd a passé du temps ou ce qui l'a bloqué avec systemd-analyze blame et systemd-analyze critical-chain, qui affiche la chaîne d'unités critique en temps pour une cible.
• Sur la ligne de commande du noyau, passer systemd.unit= pour choisir une autre cible de démarrage (par exemple rescue.target) pour un seul démarrage, sans modifier aucun fichier, conformément à kernel-command-line(7) ; la forme préfixée par rd. (rd.systemd.unit=) ne s'applique qu'à l'intérieur de l'initramfs.
• Si aucun écran de connexion n'apparaît, vérifier d'abord l'étape firmware/chargeur d'amorçage (le menu de démarrage s'affiche-t-il seulement ?) avant de supposer que le noyau ou systemd est en cause.

Pièges

• Lire journalctl -b alors que le démarrage en échec a déjà été remplacé par un démarrage réussi ; utiliser -b -1, -b -2, etc. (journalctl --list-boots indique ce qui est disponible), en notant qu'un journal non persistant perd entièrement les démarrages antérieurs.
• systemd-analyze blame ne signale pas les services Type=simple, car systemd les considère comme démarrés immédiatement ; un service simple lent n'y apparaîtra donc pas.
• Supposer qu'un écran muet après l'écran de démarrage du firmware signifie « le noyau a planté », alors qu'il peut s'agir simplement d'une animation de démarrage graphique qui masque les messages du noyau ; supprimer quiet splash (Debian/Ubuntu) ou rhgb quiet (famille RHEL) pour un démarrage dans l'éditeur de GRUB afin de voir la sortie réelle.