infra / linux-bash

Processus de boot : GRUB et initramfs

Leçon 291 exercice

Explication

Ce que vous allez apprendre

Décrire la séquence complète de démarrage, du firmware au premier processus utilisateur
Comprendre pourquoi l'initramfs existe (le paradoxe des pilotes nécessaires pour accéder au disque)
Ne jamais éditer grub.cfg directement, toujours passer par update-grub
Diagnostiquer un boot lent avec systemd-analyze blame
Consulter les logs d'un démarrage précédent après un crash avec journalctl -b -1

Dans quel contexte ?

Un serveur ne redémarre plus après une mise à jour noyau. Comprendre précisément la séquence de boot (firmware → GRUB → initramfs → systemd) te dit exactement à quelle étape chercher le problème, plutôt que de réinstaller le système en panique.

Étape	Rôle	Composant
1. Firmware	Auto-tests matériels, choisit le disque de boot	BIOS / UEFI
2. Bootloader	Charge le noyau et l'initramfs en mémoire	GRUB2
3. Initramfs	Mini-système temporaire, charge les pilotes du vrai disque	initramfs
4. Init	Démarre les services jusqu'à la cible par défaut	systemd

D'abord, la question que cette leçon répond

Une machine qui ne démarre plus est l'un des scénarios les plus stressants pour un administrateur système. Comprendre précisément ce qui se passe entre l'allumage et le premier prompt permet de savoir où chercher quand ça casse.

Voici la première étape : le firmware choisit un disque

Le BIOS ou l'UEFI fait ses auto-tests matériels puis sélectionne un disque de démarrage. C'est ce disque qui contient le bootloader, GRUB2 sur la quasi-totalité des distributions Linux modernes.

Une fois GRUB lancé, il charge deux choses en mémoire

GRUB charge à la fois le noyau Linux et un fichier appelé l'initramfs. Ce n'est pas un détail : le noyau a souvent besoin de pilotes spécifiques (RAID, chiffrement) pour accéder au vrai disque, mais ces pilotes sont eux-mêmes stockés sur ce disque — un paradoxe que l'initramfs résout en étant un mini-système temporaire chargé directement en mémoire.

Il reste une règle à connaître avant de toucher à GRUB

Le fichier /boot/grub/grub.cfg est généré automatiquement à partir de /etc/default/grub et des scripts dans /etc/grub.d/. L'éditer directement fonctionne temporairement, mais la prochaine régénération (sudo update-grub) écrasera silencieusement tes changements : modifie toujours la source, jamais le fichier final.

Piège classique

Ne jamais éditer /boot/grub/grub.cfg à la main : c'est un fichier généré, sudo update-grub l'écrasera silencieusement à la prochaine régénération. Modifie toujours /etc/default/grub, jamais le résultat final.

Maintenant, que se passe-t-il après l'initramfs

Une fois le vrai disque racine monté, un pivot_root bascule dessus et lance /sbin/init, qui est systemd sur la plupart des distributions modernes. systemd démarre alors les services jusqu'à atteindre sa cible par défaut, comme multi-user.target.

Un dernier outil pour diagnostiquer un boot lent

systemd-analyze blame classe chaque service par temps de démarrage décroissant, révélant immédiatement lequel ralentit le boot. journalctl -b -1 donne accès aux logs du démarrage précédent, indispensable pour comprendre un crash après un redémarrage forcé.

Le piège à connaître

Régénérer grub.cfg avec la mauvaise commande selon la distribution (update-grub sur Debian/Ubuntu contre grub2-mkconfig -o /boot/grub2/grub.cfg sur RHEL/Fedora) est une confusion fréquente. Maintenant que tu maîtrises le démarrage, la prochaine leçon explore ce qui se passe quand la mémoire vient à manquer une fois le système lancé.

Commandes & code

Processus de boot : GRUB et initramfs

# Séquence de boot simplifiée (BIOS/UEFI -> noyau -> espace utilisateur)
1. Firmware (BIOS legacy ou UEFI) : auto-tests matériels, sélectionne le disque de boot
2. Bootloader (GRUB2) : affiche le menu, charge le noyau ET l'initramfs en mémoire
3. Noyau Linux : s'initialise, monte l'initramfs comme racine temporaire
4. initramfs : charge les modules/pilotes nécessaires pour accéder au VRAI disque racine
5. pivot_root vers le disque réel, puis lancement de /sbin/init (systemd en général)
6. systemd : atteint la cible par défaut (default.target), démarre les services

# --- GRUB : configuration ---
cat /etc/default/grub
# GRUB_DEFAULT=0                    # entrée de menu par défaut
# GRUB_TIMEOUT=5                    # secondes avant boot automatique
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"   # paramètres passés au noyau

sudo nano /etc/default/grub          # éditer la config
sudo update-grub                       # Debian/Ubuntu : régénère /boot/grub/grub.cfg
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/Fedora : équivalent

# JAMAIS éditer /boot/grub/grub.cfg directement : il est régénéré, tes changements seraient perdus

# Voir les entrées de menu disponibles
grep ^menuentry /boot/grub/grub.cfg

# Ajouter un paramètre noyau au boot suivant uniquement (sans modifier la config, via l'invite GRUB)
# Au démarrage : touche 'e' sur l'entrée -> éditer la ligne "linux" -> Ctrl+X pour démarrer avec

# --- initramfs (initial RAM filesystem) : mini-système chargé avant le disque réel ---
lsinitramfs /boot/initrd.img-$(uname -r) | head -20     # liste le contenu (Debian/Ubuntu)
lsinitrd /boot/initramfs-$(uname -r).img                   # équivalent (RHEL/Fedora, dracut)

# Régénérer l'initramfs (après ajout d'un module, changement de disque, LUKS...)
sudo update-initramfs -u -k $(uname -r)      # Debian/Ubuntu, pour le noyau courant
sudo update-initramfs -u -k all                # pour TOUS les noyaux installés
sudo dracut --force                              # RHEL/Fedora

# --- Récupération : réparer un système qui ne boote plus ---
# Depuis le menu GRUB, ajouter à la ligne linux : init=/bin/bash
# -> démarre directement un shell root, sans systemd, filesystem souvent en lecture seule
mount -o remount,rw /                # remonte la racine en lecture-écriture pour réparer

# --- systemd : cibles de boot (équivalent moderne des runlevels) ---
systemctl get-default                  # cible par défaut (multi-user.target, graphical.target...)
sudo systemctl set-default multi-user.target    # boot sans interface graphique
systemctl list-dependencies default.target        # tout ce qui démarre pour atteindre cette cible

# Analyser le temps de démarrage
systemd-analyze                          # temps total (firmware + bootloader + noyau + userspace)
systemd-analyze blame                      # classe les services par temps de démarrage décroissant
systemd-analyze critical-chain               # chaîne critique qui détermine le temps de boot minimal

# Logs du boot le plus récent
journalctl -b                              # tous les logs depuis le dernier démarrage
journalctl -b -1                             # boot précédent (utile après un crash)
dmesg | grep -i error                          # erreurs remontées par le noyau au boot

Résumé

GRUB charge noyau + initramfs ; toujours passer par update-grub/grub2-mkconfig, jamais éditer grub.cfg à la main.
L'initramfs contient juste assez de pilotes pour monter le VRAI disque racine — à régénérer après un changement de stockage/module.
systemd-analyze blame et journalctl -b sont les deux réflexes pour diagnostiquer un boot lent ou en échec.

Exercices pratiques

1 disponible

Mission : un serveur qui ne redémarre plus après une mise à jour noyau

Objectif : Retracer la séquence de boot pour localiser précisément où chercher, et diagnostiquer un boot lent ou en échec.

Contexte

Un serveur ne redémarre plus après une mise à jour noyau. Plutôt que de réinstaller le système en panique, tu dois localiser précisément à quelle étape de la séquence de boot le problème se situe.

Résoudre l’exercice →