Démarrage et init

Show code cell source

Hide code cell source

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

De la mise sous tension au shell

Quand vous appuyez sur le bouton d’alimentation d’un serveur ou d’un poste de travail Linux, une longue séquence d’événements se déroule avant que l’invite de commande apparaisse. Chaque étape dépend de la précédente, et une défaillance à n’importe quel maillon interrompt le démarrage — c’est pourquoi comprendre cette séquence est indispensable pour diagnostiquer les pannes et administrer efficacement un système.

La séquence de démarrage se décompose en cinq grandes phases :

1. Firmware (BIOS/UEFI) — le matériel s’initialise, le firmware cherche un périphérique d’amorçage.

2. Chargeur d’amorçage (GRUB2) — un petit programme charge le noyau Linux depuis le disque.

3. Noyau Linux — le noyau se décompresse, détecte le matériel, monte un système de fichiers temporaire.

4. initramfs — un mini-système de fichiers en RAM prépare l’environnement nécessaire au montage du vrai /.

5. Systemd (PID 1) — le gestionnaire de services orchestre le démarrage complet jusqu’à l’invite de connexion.

Vue d’ensemble

La durée totale de démarrage d’un serveur Linux moderne va de quelques secondes (SSD NVMe, systemd optimisé) à plus d’une minute (HDD rotatif, services nombreux). La commande systemd-analyze mesure chaque phase avec précision.

Show code cell source

Hide code cell source

# Diagramme de la séquence de boot — durées approximatives en secondes
phases = [
    ("Firmware\n(BIOS/UEFI)", 3.2, "#4878CF"),
    ("GRUB2", 1.1, "#6ACC65"),
    ("Chargement\nnoyau", 0.8, "#D65F5F"),
    ("initramfs", 1.5, "#B47CC7"),
    ("Systemd\nspace user", 4.4, "#C4AD66"),
]

fig, ax = plt.subplots(figsize=(11, 3.5))
cumul = 0
bars = []
for label, dur, color in phases:
    bar = ax.barh(0, dur, left=cumul, height=0.5, color=color, edgecolor="white", linewidth=1.5)
    ax.text(cumul + dur / 2, 0, f"{label}\n{dur:.1f}s",
            ha="center", va="center", fontsize=9, color="white", fontweight="bold")
    cumul += dur

ax.set_xlim(0, cumul + 0.5)
ax.set_yticks([])
ax.set_xlabel("Temps depuis la mise sous tension (secondes)")
ax.set_title("Séquence de démarrage Linux — répartition des phases")
ax.spines[["top", "left", "right"]].set_visible(False)
plt.show()

La durée de chaque phase varie considérablement d’un système à l’autre. Ce qui est constant, c’est l”ordre : il n’est pas possible de démarrer systemd avant que le noyau soit en mémoire, ni de charger le noyau avant que GRUB2 l’ait localisé sur le disque.

Démarrage réseau (PXE / netboot)

Dans les environnements datacenter, les serveurs démarrent souvent depuis le réseau via PXE (Preboot eXecution Environment). Le firmware UEFI charge un mini-programme depuis un serveur DHCP/TFTP qui fournit ensuite le noyau et l’initramfs. Le reste de la séquence de boot est identique — seul le transport du chargeur d’amorçage change.

BIOS vs UEFI

Le BIOS (Basic Input/Output System)

Le BIOS est le firmware historique des PC, présent depuis les années 1980. Stocké sur une puce flash de la carte mère, il s’exécute immédiatement après la mise sous tension et réalise le POST (Power-On Self-Test) : vérification du processeur, de la RAM, des périphériques de base. Le BIOS cherche ensuite un périphérique d’amorçage en lisant le MBR (Master Boot Record), les 512 premiers octets du disque.

Limitation du MBR

Le MBR ne peut adresser que des disques jusqu’à 2 To et ne supporte que 4 partitions primaires. Ces limitations ont imposé le passage à GPT (GUID Partition Table) et à UEFI.

Le MBR contient le stage 1 de GRUB, un code minuscule (446 octets utiles) qui sait uniquement charger le stage 1.5 ou stage 2 depuis le disque. L’interface BIOS est configurée via un menu accessible au démarrage (Del, F2, F10 selon les fabricants) et ne propose ni interface graphique moderne ni sécurité cryptographique.

UEFI (Unified Extensible Firmware Interface)

L’UEFI est le successeur du BIOS, standardisé par l’UEFI Forum depuis 2005. Les différences fondamentales avec le BIOS sont les suivantes :

• Partition ESP (EFI System Partition) : une partition FAT32 dédiée, montée sur /boot/efi, contient les chargeurs d’amorçage sous forme de fichiers .efi. Plus besoin de code dans le MBR.

• Support GPT natif : disques jusqu’à 9,4 Zo, 128 partitions primaires.

• Secure Boot : mécanisme cryptographique qui vérifie la signature des chargeurs d’amorçage et du noyau avant de les exécuter, empêchant les bootkits.

• Interface graphique : curseur souris, résolutions élevées, shell UEFI interactif.

• Network Boot (PXE) intégré, drivers réseau en mode firmware.

ESP sous Linux

Sur un système UEFI, la partition ESP est généralement /dev/sdaX ou /dev/nvme0n1p1, montée sur /boot/efi. Le chargeur GRUB2 y est installé sous /boot/efi/EFI/ubuntu/grubx64.efi (ou la distribution correspondante). La variable NVRAM de la carte mère pointe vers ce fichier.

Secure Boot

Secure Boot est une fonctionnalité UEFI qui crée une chaîne de confiance depuis le firmware jusqu’au noyau. Le firmware maintient une base de données de clés publiques de confiance (db) et une liste de révocation (dbx). Chaque composant (GRUB2, le noyau) doit être signé avec une clé privée dont la clé publique est dans db.

Secure Boot et noyaux personnalisés

Compiler un noyau personnalisé ou charger des modules non signés nécessite soit de désactiver Secure Boot dans l’UEFI, soit de créer et d’enregistrer sa propre clé Machine Owner Key (MOK) via mokutil. Ne désactivez pas Secure Boot sans comprendre les implications sécuritaires.

Show code cell source

Hide code cell source

# Tableau comparatif BIOS vs UEFI
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches

fig, ax = plt.subplots(figsize=(11, 5))
ax.axis("off")

colonnes = ["Critère", "BIOS", "UEFI"]
lignes = [
    ["Standard", "Propriétaire (IBM PC, 1981)", "UEFI Forum (2005, v2.x)"],
    ["Table de partitions", "MBR (max 2 To, 4 primaires)", "GPT (max 9,4 Zo, 128 partitions)"],
    ["Chargeur d'amorçage", "Code dans MBR (446 octets)", "Fichiers .efi sur partition ESP (FAT32)"],
    ["Interface config.", "Texte, clavier uniquement", "Graphique, souris, résolutions élevées"],
    ["Secure Boot", "Non", "Oui (chaîne de confiance cryptographique)"],
    ["Mode 32/64 bits", "16 bits (mode réel)", "32 ou 64 bits (mode protégé/long)"],
    ["Démarrage réseau", "PXE optionnel (option ROM)", "PXE intégré, IPv4 et IPv6"],
    ["Temps init.", "Lent (POST séquentiel)", "Rapide (initialisation parallèle)"],
]

table = ax.table(
    cellText=lignes,
    colLabels=colonnes,
    loc="center",
    cellLoc="left",
)
table.auto_set_font_size(False)
table.set_fontsize(9)
table.scale(1, 1.6)

# Style de l'en-tête
for j in range(len(colonnes)):
    table[0, j].set_facecolor("#4878CF")
    table[0, j].set_text_props(color="white", fontweight="bold")

# Alternance de couleurs
for i in range(1, len(lignes) + 1):
    for j in range(len(colonnes)):
        if i % 2 == 0:
            table[i, j].set_facecolor("#f0f4fb")
        else:
            table[i, j].set_facecolor("#ffffff")

ax.set_title("BIOS vs UEFI — comparaison des firmwares", fontsize=12, fontweight="bold", pad=20)
plt.show()

GRUB2

Rôle de GRUB2

GRUB2 (GRand Unified Bootloader version 2) est le chargeur d’amorçage standard des distributions Linux. Son rôle est de :

1. Localiser et charger le noyau Linux depuis le système de fichiers.

2. Passer au noyau les paramètres de démarrage (kernel command line).

3. Charger l’image initramfs en mémoire.

4. Transférer le contrôle au noyau.

GRUB2 est capable de lire les systèmes de fichiers ext4, btrfs, xfs, FAT32, etc., ce qui lui permet d’accéder directement à /boot/vmlinuz-* et /boot/initrd.img-* sans assistance extérieure.

Fichiers de configuration

GRUB2 distingue deux niveaux de configuration :

/etc/default/grub — fichier de configuration utilisateur, éditable. Définit les options globales :

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
GRUB_DISTRIBUTOR="Ubuntu"

/boot/grub/grub.cfg — fichier généré automatiquement à partir des scripts dans /etc/grub.d/. Ne jamais éditer directement. Régénéré par :

# Debian/Ubuntu
update-grub

# Fedora/RHEL
grub2-mkconfig -o /boot/grub2/grub.cfg

Ne jamais éditer grub.cfg manuellement

Le fichier /boot/grub/grub.cfg est regénéré à chaque mise à jour du noyau. Toute modification manuelle sera écrasée. Les personnalisations permanentes s’effectuent dans /etc/default/grub et dans les scripts /etc/grub.d/40_custom.

GRUB2 et les systèmes chiffrés

Sur un système avec chiffrement LUKS complet (/boot inclus), GRUB2 doit être capable de déchiffrer la partition /boot pour lire le noyau. Cela nécessite de configurer GRUB_ENABLE_CRYPTODISK=y dans /etc/default/grub et d’ajouter les modules LUKS à l’image GRUB. Le mot de passe LUKS sera demandé deux fois : une par GRUB, une par l’initramfs.

Paramètres importants de /etc/default/grub

Paramètre	Rôle
GRUB_TIMEOUT	Délai d’attente en secondes avant de booter l’entrée par défaut
GRUB_DEFAULT	Indice (0-based) ou nom de l’entrée par défaut
GRUB_CMDLINE_LINUX_DEFAULT	Paramètres passés au noyau pour les démarrages normaux
GRUB_CMDLINE_LINUX	Paramètres passés au noyau pour tous les démarrages (y compris rescue)
GRUB_DISABLE_RECOVERY	Désactive les entrées de mode de récupération
GRUB_TERMINAL_INPUT	Interface d’entrée (console, serial)

Mode rescue et recovery

Si le système ne démarre plus, GRUB2 propose plusieurs mécanismes de secours :

Entrée recovery mode (Ubuntu/Debian) : ajoute single ou recovery aux paramètres kernel, démarre en runlevel 1 avec uniquement le minimum de services.

Shell GRUB2 : en appuyant sur c dans le menu GRUB, un shell interactif permet de monter des partitions, explorer les systèmes de fichiers et démarrer manuellement :

# Dans le shell GRUB2
grub> set root=(hd0,gpt2)
grub> linux /vmlinuz-6.1.0-amd64 root=/dev/sda3 ro
grub> initrd /initrd.img-6.1.0-amd64
grub> boot

Rescue mode : si grub.cfg est absent ou corrompu, GRUB2 tombe automatiquement dans un shell grub rescue> encore plus minimal.

Réinstallation de GRUB2

Après une corruption de GRUB2, la procédure standard est de démarrer depuis un LiveCD, monter les partitions du système cible, chroot dedans, et relancer grub-install /dev/sdX && update-grub. Cette procédure fonctionne même si le système ne démarre plus du tout.

Le noyau : chargement et initialisation

Du fichier au processeur

GRUB2 charge en mémoire deux fichiers :

• /boot/vmlinuz-<version> — le noyau compressé (format bzImage). Le préfixe vm signifie virtual memory, z indique la compression.

• /boot/initrd.img-<version> — l’image initramfs (archive cpio compressée).

Le noyau se décompresse lui-même en mémoire, puis s’exécute. Sa première tâche est l”initialisation de l’architecture : configuration du CPU (mode 64 bits, pagination, interruptions), détection de la RAM, mise en place des structures internes (tables de pages, listes de processus).

Détection du matériel

Le noyau détecte le matériel via :

• ACPI (Advanced Configuration and Power Interface) : tables fournie par l’UEFI/BIOS décrivant la topologie matérielle, la gestion de l’énergie, les interruptions.

• Device Tree : sur les architectures ARM/RISC-V, un arbre de données statique décrit le matériel (pas de découverte dynamique comme PCI).

• PCI enumeration : le noyau parcourt le bus PCI pour inventorier les périphériques et charger les pilotes appropriés.

Paramètres kernel (/proc/cmdline)

Les paramètres passés par GRUB2 au noyau sont visibles dans /proc/cmdline :

cat /proc/cmdline
# BOOT_IMAGE=/boot/vmlinuz-6.1.0-amd64 root=UUID=a1b2c3d4-... ro quiet splash

Paramètres kernel courants

• root= : périphérique racine (UUID ou chemin)

• ro / rw : monte la racine en lecture seule ou lecture-écriture

• quiet : réduit les messages kernel au démarrage

• splash : affiche l’écran de démarrage graphique

• single : démarre en mode single-user (runlevel 1)

• init= : remplace systemd par un binaire alternatif (ex: init=/bin/bash pour le debug)

• nomodeset : désactive le mode kernel pour les pilotes graphiques (dépannage GPU)

• mem= : limite la mémoire utilisable (ex: mem=4G)

initramfs

Rôle

Le noyau, une fois chargé, doit monter le système de fichiers racine /. Mais pour cela, il peut avoir besoin de pilotes spécifiques : pilote RAID logiciel, support LVM, chiffrement LUKS, pilotes SCSI ésotériques… Ces pilotes eux-mêmes sont stockés sur le disque qui n’est pas encore monté — paradoxe du bootstrap.

La solution est l”initramfs (initial RAM filesystem) : une archive cpio compressée contenant un mini-système de fichiers avec les pilotes et scripts strictement nécessaires au montage de /. Le noyau la décompresse directement en RAM et l’utilise comme racine temporaire.

initrd vs initramfs

Les deux termes sont souvent confondus. L’initrd (initial ramdisk) est l’ancienne approche : un vrai périphérique bloc en RAM. L’initramfs est plus moderne : un système de fichiers tmpfs extrait d’une archive cpio. Linux utilise initramfs depuis le noyau 2.6. Le fichier s’appelle encore souvent initrd.img par tradition.

Contenu d’une initramfs

Une initramfs typique contient :

/bin/        → busybox, shell minimal
/lib/        → modules noyau nécessaires (LUKS, LVM, RAID)
/sbin/       → fsck, cryptsetup, lvm, mdadm
/scripts/    → scripts de montage (Debian/Ubuntu : scripts/local)
/init        → script principal (ou binaire systemd dans les systèmes modernes)
/etc/        → configuration minimale

initramfs et les distributions modernes

Les distributions modernes (Debian 12+, Ubuntu 22.04+) utilisent systemd comme /init dans l’initramfs, remplaçant les scripts shell traditionnels. Cette approche unifiée apporte la journalisation, la gestion des unités et le debug via systemd.debug-shell=1 sur la ligne de commande du noyau, qui ouvre un shell d’urgence très tôt dans le démarrage.

Pour inspecter le contenu d’une initramfs :

# Extraire et lister le contenu (non-exécutable ici)
mkdir /tmp/initramfs-extract
cd /tmp/initramfs-extract
unmkinitramfs /boot/initrd.img-$(uname -r) .
ls -la

Mise à jour

# Debian/Ubuntu — regénérer l'initramfs pour le noyau courant
update-initramfs -u

# Pour un noyau spécifique
update-initramfs -u -k 6.1.0-amd64

# Fedora/RHEL — avec dracut
dracut --force

# Vérifier la date de génération
ls -lh /boot/initrd.img-*

Quand regénérer l’initramfs

Il faut regénérer l’initramfs après : l’ajout d’un disque chiffré LUKS, la mise en place de LVM, le changement de pilotes réseau utilisés pour un NFS root, ou l’installation de modules noyau critiques au démarrage. Un initramfs obsolète peut empêcher le démarrage après une migration matérielle.

Systemd comme PID 1

Pourquoi PID 1 est spécial

Le premier processus lancé par le noyau Linux reçoit le PID 1. C’est le seul processus qui n’a pas de processus parent — ou plutôt, son parent est le noyau lui-même. Il a deux responsabilités uniques :

1. Adopter les processus orphelins : tout processus dont le parent meurt est réattaché au PID 1.

2. Être immortel : si le PID 1 se termine, le noyau panique et le système s’arrête.

Historiquement, le PID 1 était SysV init (script /etc/inittab, runlevels 0-6) ou Upstart (Ubuntu). Depuis 2011-2015, systemd s’est imposé comme standard sur presque toutes les distributions majeures.

Unités systemd

Systemd organise tout en unités (units). Une unité est décrite par un fichier de configuration dont l’extension indique le type :

Extension	Type	Rôle
.service	Service	Processus daemon (nginx, sshd, postgresql…)
.socket	Socket	Activation à la demande par connexion
.target	Target	Groupement d’unités (équivalent runlevel)
.timer	Timer	Déclenchement planifié (remplace cron)
.mount	Mount	Point de montage
.device	Device	Périphérique noyau (via udev)
.path	Path	Surveillance de fichier/répertoire
.scope	Scope	Groupe de processus externes
.slice	Slice	Hiérarchie cgroup de contrôle des ressources

Targets (cibles)

Les targets sont l’équivalent systemd des runlevels SysV. Elles définissent un état du système en agrégeant des dépendances :

Target	Équivalent SysV	Description
poweroff.target	runlevel 0	Arrêt du système
rescue.target	runlevel 1	Mode maintenance mono-utilisateur
multi-user.target	runlevel 3	Multi-utilisateur, sans interface graphique
graphical.target	runlevel 5	Multi-utilisateur avec interface graphique
reboot.target	runlevel 6	Redémarrage
emergency.target	—	Shell d’urgence, avant montage de /

# Changer de target immédiatement
systemctl isolate multi-user.target

# Définir la target par défaut
systemctl set-default graphical.target

# Voir la target par défaut
systemctl get-default

Ordre de démarrage systemd

Systemd démarre les unités en tenant compte de leurs dépendances déclarées (Requires=, Wants=, After=, Before=). Le graphe de dépendances permet une parallélisation maximale : les services sans dépendances entre eux démarrent simultanément, d’où les gains de vitesse considérables par rapport à SysV init (démarrage séquentiel).

Parallélisation et activation par socket

Systemd pousse la parallélisation encore plus loin grâce à l’activation par socket. Le socket d’un service (par exemple le socket D-Bus) est créé immédiatement au démarrage, même si le service n’est pas encore prêt. Les clients peuvent tenter de s’y connecter ; leurs messages sont mis en file d’attente jusqu’à ce que le service soit opérationnel. Cela permet de démarrer des services interdépendants en parallèle.

Analyse du temps de démarrage

systemd-analyze

Systemd fournit un outil dédié à l’analyse des performances de démarrage :

# Temps total de démarrage
systemd-analyze time
# Startup finished in 3.245s (firmware) + 1.102s (loader) + 0.821s (kernel) + 4.412s (userspace) = 9.580s
# graphical.target reached after 4.388s in userspace

# Détail des services les plus lents
systemd-analyze blame
# 2.341s NetworkManager-wait-online.service
# 1.203s apt-daily-upgrade.service
# ...

# Graphe critique des dépendances
systemd-analyze critical-chain

# Générer un SVG de la timeline complète
systemd-analyze plot > boot-timeline.svg

Optimisation du démarrage

Le service NetworkManager-wait-online.service est l’un des plus fréquents coupables de ralentissement. Si votre système n’a pas besoin d’attendre le réseau pour démarrer, désactivez-le : systemctl disable NetworkManager-wait-online.service. Gain typique : 1 à 3 secondes.

Show code cell source

Hide code cell source

# Simulation d'une sortie de systemd-analyze blame
# Données représentatives d'un système Ubuntu Desktop

import matplotlib.pyplot as plt
import seaborn as sns
import pandas as pd

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

blame_data = {
    "service": [
        "NetworkManager-wait-online.service",
        "apt-daily-upgrade.service",
        "snapd.service",
        "ModemManager.service",
        "udisks2.service",
        "accounts-daemon.service",
        "avahi-daemon.service",
        "cups.service",
        "NetworkManager.service",
        "bluetooth.service",
        "systemd-udev-settle.service",
        "polkit.service",
        "rsyslog.service",
        "ssh.service",
        "cron.service",
    ],
    "duree_ms": [
        2341, 1203, 987, 612, 534,
        421, 398, 376, 312, 287,
        243, 198, 156, 134, 112,
    ],
}

df = pd.DataFrame(blame_data).sort_values("duree_ms", ascending=True)

fig, ax = plt.subplots(figsize=(10, 6))
colors = sns.color_palette("muted", len(df))
bars = ax.barh(df["service"], df["duree_ms"] / 1000, color=colors, edgecolor="none")

for bar, val in zip(bars, df["duree_ms"]):
    ax.text(val / 1000 + 0.02, bar.get_y() + bar.get_height() / 2,
            f"{val}ms", va="center", fontsize=8.5)

ax.set_xlabel("Durée de démarrage (secondes)")
ax.set_title("systemd-analyze blame — services les plus lents au démarrage")
ax.spines[["top", "right"]].set_visible(False)
plt.show()

Show code cell source

Hide code cell source

# Visualisation des phases de démarrage avec annotations temporelles

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

phases = {
    "Firmware": (0, 3.245, "#4878CF"),
    "GRUB2\n(loader)": (3.245, 1.102, "#6ACC65"),
    "Noyau\n(kernel)": (4.347, 0.821, "#D65F5F"),
    "Espace\nutilisateur": (5.168, 4.412, "#B47CC7"),
}

fig, axes = plt.subplots(2, 1, figsize=(11, 5),
                         gridspec_kw={"height_ratios": [2, 1]})

# Graphique principal : timeline
ax = axes[0]
y_pos = 0
legend_patches = []

for nom, (debut, duree, couleur) in phases.items():
    ax.barh(y_pos, duree, left=debut, height=0.5,
            color=couleur, edgecolor="white", linewidth=2)
    ax.text(debut + duree / 2, y_pos, f"{nom}\n{duree:.3f}s",
            ha="center", va="center", fontsize=9, color="white", fontweight="bold")
    legend_patches.append(mpatches.Patch(color=couleur, label=f"{nom.replace(chr(10), ' ')}: {duree:.3f}s"))

ax.set_xlim(0, 10)
ax.set_yticks([])
ax.set_xlabel("Temps (secondes)")
ax.set_title("Décomposition du temps de démarrage — systemd-analyze time")
ax.axvline(x=9.58, color="black", linestyle="--", alpha=0.6, linewidth=1)
ax.text(9.58, 0.32, "  Total: 9.58s", fontsize=9, va="center")
ax.legend(handles=legend_patches, loc="lower right", fontsize=8)
ax.spines[["top", "left", "right"]].set_visible(False)

# Graphique secondaire : proportion de chaque phase
ax2 = axes[1]
durees = [v[1] for v in phases.values()]
noms = [k.replace("\n", " ") for k in phases.keys()]
couleurs = [v[2] for v in phases.values()]
wedges, texts, autotexts = ax2.pie(
    durees, labels=noms, colors=couleurs,
    autopct="%1.0f%%", startangle=90,
    textprops={"fontsize": 9},
)
ax2.set_title("Proportion de chaque phase", fontsize=10)

plt.show()

Résumé

Le démarrage d’un système Linux est une séquence rigoureusement ordonnée de cinq étapes, chacune préparant le terrain pour la suivante :

Étape	Acteur	Rôle clé
1	Firmware (BIOS/UEFI)	POST, localisation du chargeur d’amorçage
2	GRUB2	Chargement du noyau et de l’initramfs en mémoire
3	Noyau Linux	Initialisation CPU/RAM, montage initramfs
4	initramfs	Préparation des pilotes, montage du vrai /
5	Systemd (PID 1)	Démarrage parallèle des services jusqu’à la target

Points clés à retenir

• UEFI remplace BIOS : partition ESP, Secure Boot, support GPT natif.

• GRUB2 lit les systèmes de fichiers directement ; sa configuration maître est /etc/default/grub, jamais grub.cfg.

• L’initramfs résout le paradoxe du bootstrap : les pilotes nécessaires au montage de / sont chargés depuis la RAM.

• Systemd parallélise le démarrage via un graphe de dépendances ; systemd-analyze blame identifie les goulots d’étranglement.

• Les paramètres kernel (/proc/cmdline) permettent de modifier le comportement au démarrage sans recompiler le noyau.

Commandes de diagnostic essentielles

# Temps de démarrage décomposé
systemd-analyze time

# Services les plus lents
systemd-analyze blame

# Chaîne critique de dépendances
systemd-analyze critical-chain graphical.target

# Paramètres passés au noyau
cat /proc/cmdline

# Version et date de compilation du noyau
uname -a