Debian 13 bloqué dans initramfs : ce que cela signifie vraiment et comment récupérer votre système

novembre 26, 2025 • février 3, 2026 • Lecture : 29 min • Views: 5

Cet article vous a aidé ?

Vous redémarrez après une mise à jour du noyau ou une modification de stockage de routine, et au lieu d’un prompt de connexion vous obtenez un petit shell qui a l’air d’avoir été conçu à l’ère dot-com : (initramfs). Pas de réseau. Pas de services. Juste vous et un système de fichiers qui ne se monte pas.

Ce n’est pas « Linux qui a planté ». C’est Linux qui dit la vérité : la chaîne de démarrage a rencontré une dépendance critique (généralement liée au stockage), et elle a refusé de faire semblant. Votre tâche est d’identifier quelle dépendance a échoué, la réparer avec un minimum de bricolage, puis reconstruire les artefacts de démarrage pour ne pas retrouver ce shell au prochain reboot.

Ce qu’« initramfs » est vraiment (et ce que ce n’est pas)

Quand Debian vous laisse dans (initramfs), vous n’êtes pas encore « dans Debian ». Vous êtes dans un petit environnement d’exécution temporaire chargé en RAM par le noyau. Son rôle est d’effectuer le travail de démarrage précoce : découvrir votre stockage, charger les modules du noyau, assembler RAID/LVM, déverrouiller le chiffrement et monter le vrai système de fichiers racine. Une fois cela réussi, switch_root (ou équivalent) cède le contrôle au véritable espace utilisateur.

Si ce transfert ne peut pas avoir lieu, initramfs s’arrête. Il vous donne un shell parce que c’est le dernier endroit sûr pour dépanner : avant les services, avant la rotation des logs, avant que quoi que ce soit ne soit monté en lecture-écriture et ne rende la récupération plus difficile.

La plupart du temps, « bloqué dans initramfs » signifie l’un des cas suivants :

Le noyau ne voit pas le périphérique qui devrait être root (pilote/module manquant, nom du périphérique changé, disque en panne).
Le périphérique existe, mais l’identifiant ne correspond pas (UUID/PARTUUID erroné dans GRUB ou dans /etc/fstab).
Le root est en couches (LUKS, LVM, mdadm RAID, multipath) et les couches ne se sont pas assemblées dans l’initramfs.
Le système de fichiers est suffisamment endommagé pour que le montage échoue, et initramfs refuse de continuer.

Vérité sèche : le shell initramfs n’est pas une punition. C’est une porte coupe-feu. Vous pouvez soit l’utiliser méthodiquement, soit paniquer et scroller des commandes aléatoires jusqu’à empirer la situation. Choisissez la méthode.

Blague #1 : Le shell initramfs est comme la file de sécurité d’un aéroport : ce n’est pas l’endroit où vous vouliez être, mais c’est là que les choses manquantes se font remarquer.

Playbook de diagnostic rapide (vérifier premier/deuxième/troisième)

Ceci est la séquence « arrêter l’hémorragie ». Ne commencez pas par réinstaller GRUB. Ne commencez pas par éditer des UUID au hasard. Commencez par prouver ce qui existe, puis ce qui devrait exister, puis pourquoi ils diffèrent.

Premier : voyons-nous les disques et les bons modules du noyau ?

Vérifiez quels périphériques bloc existent (lsblk).
Vérifiez si le module de contrôleur attendu est chargé (lsmod).
Cherchez « timed out » ou « unknown-block » dans le journal du noyau (dmesg).

Deuxième : pouvons-nous identifier sans ambiguïté le périphérique root prévu ?

Listez les UUID/PARTUUID des systèmes de fichiers (blkid).
Vérifiez ce que la ligne de commande du noyau utilise (cat /proc/cmdline).
Confirmez si root est sur une partition simple, LVM, mdadm RAID ou LUKS.

Troisième : pouvons-nous assembler les couches et monter root en lecture seule ?

Si RAID : mdadm --assemble --scan, puis revérifiez /proc/mdstat.
Si LVM : vgscan, vgchange -ay, puis lvs.
Si LUKS : cryptsetup luksOpen, puis montez le périphérique mappé.
Montez root en lecture seule et inspectez les logs/config : mount -o ro … /mnt.

Une fois que vous pouvez monter root, vous pouvez réparer la configuration et reconstruire initramfs/GRUB depuis un chroot. C’est le point d’inflexion : de « mystère » à « réparation contrôlée ».

Faits et histoire intéressants (ce qui explique les pannes actuelles)

Le comportement de démarrage moderne de Debian ressemble à une empilement de décisions prises sur deux décennies. Les pannes que vous voyez dans initramfs sont essentiellement ces décisions montrant leurs coutures. Un peu de contexte vous aide à diagnostiquer plus vite.

initrd précède initramfs. Les premiers Linux utilisaient un initial ramdisk (image de périphérique bloc). initramfs est passé plus tard à une archive cpio décompressée dans un tmpfs. Le « shell initramfs » que vous voyez en est un descendant.
Les UUID sont devenus populaires parce que les noms de périphériques mentent. /dev/sda peut devenir /dev/sdb selon l’ordre des contrôleurs, le timing du hotplug ou des bizarreries de firmware. Des identifiants stables (UUID/PARTUUID) ont réduit les montages accidentels du mauvais disque.
Les problèmes de timing d’udev sont réels. De nombreux « root not found » sont simplement des « root trouvé trop tard ». C’est pourquoi rootdelay= et les messages d’initramfs « waiting for root device » existent.
L’assemblage mdadm RAID a été déplacé plus tôt au démarrage pour une raison. Si votre root est sur RAID1, vous ne pouvez pas démarrer l’espace utilisateur sans assembler l’ensemble. C’est pourquoi il existe des hooks mdadm dans initramfs.
LVM c’est deux problèmes : découverte des métadonnées et activation. L’initramfs doit inclure à la fois les outils et la config pour trouver les VG, puis activer les LV afin qu’ils apparaissent comme périphériques bloc.
LUKS a fait du « prompt de mot de passe root » une fonctionnalité de démarrage. Un root chiffré signifie qu’initramfs a besoin de cryptsetup et des règles pour les clés. Si ces hooks sont manquants, le système ne peut même pas vous demander correctement la phrase de passe.
Secure Boot a changé les attentes sur les pilotes/modules. Les noyaux/modules signés et les chaînes de démarrage plus strictes signifient qu’un module manquant ou non apparié peut être fatal plus tôt qu’avant.
Les contrôles des systèmes de fichiers sont devenus plus conservateurs. Ext4 et XFS se comportent différemment en cas de corruption ; les scripts initramfs refusent souvent de monter un système de fichiers qu’ils jugent incohérent, car continuer peut causer des dommages plus graves.
GRUB n’est pas tout le démarrage. GRUB charge un noyau et un initramfs ; après cela, GRUB est essentiellement hors de l’histoire. Les gens le blâment encore parce que c’est la dernière chose dont ils se souviennent.

Modes de panne principaux qui vous déposent dans initramfs

1) Périphérique root introuvable (pilote/module manquant ou matériel modifié)

Pattern classique : vous avez changé le mode SATA dans le BIOS, déplacé un disque vers un autre contrôleur, changé le type de stockage VM (virtio ↔ SCSI), ou installé un noyau/initramfs qui n’inclut pas le bon module. Le noyau démarre, mais les nœuds de périphérique pour votre root n’apparaissent jamais.

2) UUID/PARTUUID incorrect dans GRUB ou `/etc/fstab`

Peut-être que vous avez cloné un disque, restauré depuis une sauvegarde, régénéré un système de fichiers, ou remplacé une partition. Les identifiants ont changé. Le chargeur de démarrage et la table des systèmes de fichiers pointent toujours vers les anciens.

3) RAID non assemblé assez tôt

Si le root est sur mdadm RAID, initramfs doit assembler l’ensemble. Un /etc/mdadm/mdadm.conf manquant dans initramfs, un ensemble dégradé, ou des métadonnées modifiées peuvent empêcher l’assemblage. Les périphériques existent, mais le root (l’ensemble) n’existe pas.

4) LVM non activé

Vous pouvez voir les PV, mais pas les volumes logiques. Sans que vgchange -ay s’exécute (ou sans les outils LVM du tout), root n’apparaît jamais.

5) LUKS non déverrouillé (ou fichiers-clés indisponibles)

Un root chiffré ajoute une dépendance de démarrage précoce à cryptsetup et à la possibilité de demander ou récupérer une clé. Si vous comptiez sur un fichier-clé sur une partition séparée, et que cette partition ne se monte pas, vous obtenez un blocage.

6) Le système de fichiers ne se monte pas (corruption, mauvais pilote fs, ou incompatibilité de fonctionnalités)

Ext4 monte généralement même en mauvais état (parfois trop promptement). XFS peut être strict. Btrfs peut refuser si des périphériques manquent. ZFS root ajoute sa propre logique d’import. Dans tous les cas : initramfs s’arrête parce qu’il ne peut pas monter root en toute sécurité.

7) L’initramfs lui-même est incorrect (hooks obsolètes, binaires manquants, config erronée)

Les gens reconstruisent l’initramfs moins souvent qu’ils ne devraient. Ou ils le reconstruisent une fois et oublient le deuxième noyau. Ou ils mettent à jour /etc/crypttab mais ne régénèrent pas initramfs. Ensuite ils redémarrent dans une panne parfaitement cohérente.

Tâches pratiques : commandes, sorties, décisions (12+)

Tout ce qui suit est rédigé pour le shell initramfs (style BusyBox) sauf indication contraire. Certaines commandes peuvent manquer selon la façon dont votre initramfs a été construit. Cette absence est en elle-même un signal.

Task 1: Identify where you are and what tools exist

cr0x@server:~$ uname -a
Linux (none) 6.12.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2025-01-05) x86_64 GNU/Linux
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.12.0-1-amd64 root=UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 ro quiet
cr0x@server:~$ busybox
BusyBox v1.36.1 (Debian 1:1.36.1-9) multi-call binary.

Ce que ça signifie : La version du noyau importe pour la disponibilité des pilotes. La ligne de commande vous dit ce qu’il pense que root est. BusyBox confirme que vous êtes dans un environnement minimal.

Décision : Si root=UUID=... ne correspond à aucun UUID de périphérique bloc que vous pouvez voir plus tard, vous vous dirigez vers « corriger les identifiants ». Si la cmdline utilise /dev/sdX, planifiez de migrer vers UUID/PARTUUID après la récupération.

Task 2: Look at kernel messages for storage discovery failures

cr0x@server:~$ dmesg | tail -n 40
[    2.011234] virtio_blk virtio0: [vda] 83886080 512-byte logical blocks (42.9 GB/40.0 GiB)
[    2.022110]  vda: vda1 vda2
[    6.104990] EXT4-fs (vda2): mounted filesystem with ordered data mode. Quota mode: none.
[    9.887650] VFS: Cannot open root device "UUID=4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1" or unknown-block(0,0): error -6
[    9.887690] Please append a correct "root=" boot option; here are the available partitions:
[    9.887720] 0100            4096 ram0
[    9.887740] 00ff          1048575 ram15
[    9.887760] 0b00        83886080 vda  driver: virtio_blk
[    9.887780]   0b01          1048576 vda1
[    9.887800]   0b02        82838528 vda2

Ce que ça signifie : Le noyau voit vda2, mais pas l’UUID spécifié comme root. Cela signifie généralement « UUID incorrect », pas « disque manquant ».

Décision : Passez à blkid et comparez les UUID. Si le disque lui-même n’est pas listé, orientez-vous vers des problèmes de pilote/module.

Task 3: Enumerate block devices and filesystems

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE TYPE FSTYPE UUID                                 MOUNTPOINT
vda     40G disk
├─vda1   1G part vfat   2C1A-9F33
└─vda2  39G part ext4   7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a

Ce que ça signifie : Vous avez un candidat root ext4 avec l’UUID 7e3b…, mais la cmdline de démarrage voulait 4b3f….

Décision : Soit mettez à jour le root= de GRUB vers le nouvel UUID, soit revenez au disque/partition qui a causé le changement. Habituellement : corriger la configuration et reconstruire initramfs/GRUB pour que cela persiste.

Task 4: Confirm UUIDs the old-fashioned way

cr0x@server:~$ blkid
/dev/vda1: UUID="2C1A-9F33" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="2f1e3e1b-01"
/dev/vda2: UUID="7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2f1e3e1b-02"

Ce que ça signifie : blkid est votre vérité de terrain pour les UUID des systèmes de fichiers.

Décision : Si la cmdline du noyau utilise UUID, mettez-la à jour. Si elle utilise PARTUUID, comparez celles-ci à la place. Ne devinez pas ; copiez/collez attentivement.

Task 5: Try mounting the suspected root read-only

cr0x@server:~$ mkdir -p /mnt
cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  proc  root  run  sbin  usr  var

Ce que ça signifie : Le système de fichiers se monte. Super : c’est surtout une incohérence de configuration, pas une corruption.

Décision : Inspectez /mnt/etc/fstab et la config du chargeur de démarrage, puis reconstruisez initramfs et GRUB depuis un chroot ou un environnement de secours.

Task 6: Inspect `/etc/fstab` for mismatches that will bite you later

cr0x@server:~$ sed -n '1,120p' /mnt/etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 / ext4 defaults,errors=remount-ro 0 1
UUID=2C1A-9F33  /boot/efi vfat umask=0077 0 1

Ce que ça signifie : fstab référence toujours l’ancien UUID root (4b3f…). Même si vous corrigez GRUB, vous échouerez sur des montages plus tard ou vous tomberez en mode emergency après switch_root.

Décision : Mettez à jour fstab vers 7e3b… (l’UUID réel du root), puis reconstruisez initramfs/GRUB dans le système installé pour que tout soit cohérent.

Task 7: Fix fstab safely (minimal edit, no creativity)

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak
cr0x@server:~$ sed -i 's/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a/' /mnt/etc/fstab
cr0x@server:~$ grep ' / ' /mnt/etc/fstab
/dev/disk/by-uuid/7e3b9d6b-3a43-4d7f-9f7b-41db0cfe3d2a / ext4 defaults,errors=remount-ro 0 1

Ce que ça signifie : Vous avez aligné fstab avec la réalité.

Décision : Maintenant, assurez-vous que la cmdline du noyau root= correspond aussi. C’est généralement le rôle de GRUB.

Task 8: Check whether RAID is involved (mdadm)

cr0x@server:~$ cat /proc/mdstat
Personalities : 
unused devices: <none>
cr0x@server:~$ mdadm --examine --scan
mdadm: No devices listed in conf file were found.

Ce que ça signifie : Aucun périphérique RAID n’est actuellement assemblé. Si vous attendiez des ensembles md, c’est un problème.

Décision : Si vous avez root-sur-RAID, essayez d’assembler : mdadm --assemble --scan et revérifiez /proc/mdstat. Si RAID n’était pas prévu, passez au point suivant.

Task 9: Assemble mdadm arrays (when applicable)

cr0x@server:~$ mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 vda2[0] vdb2[1]
      41361408 blocks super 1.2 [2/2] [UU]
unused devices: <none>

Ce que ça signifie : Le RAID est maintenant actif et sain ([UU]).

Décision : Si root devrait être sur /dev/md0, montez cela et corrigez la config de démarrage pour y référencer correctement (UUID du système de fichiers sur le périphérique md, ou UUID md).

Task 10: Activate LVM (when applicable)

cr0x@server:~$ vgscan
  Found volume group "vg0" using metadata type lvm2
cr0x@server:~$ vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ lvs
  LV    VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root  vg0 -wi-a----- 30.00g
  swap  vg0 -wi-a-----  8.00g

Ce que ça signifie : Les LV sont maintenant présents. Root peut être /dev/vg0/root.

Décision : Si votre système utilise LVM pour root, assurez-vous qu’initramfs inclut les hooks LVM et que root= pointe vers le LV correct (par UUID est parfois plus sûr que par nom).

Task 11: Unlock LUKS (when applicable)

cr0x@server:~$ cryptsetup luksDump /dev/vda2 | head
LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots:
  0: luks2
cr0x@server:~$ cryptsetup luksOpen /dev/vda2 cryptroot
Enter passphrase for /dev/vda2:
cr0x@server:~$ ls -l /dev/mapper/cryptroot
brw-------    1 root     root      253,   0 Dec 28 09:01 /dev/mapper/cryptroot

Ce que ça signifie : Vous avez créé un mapping déchiffré. Root peut se trouver à l’intérieur (peut‑être avec LVM au-dessus).

Décision : Si cela fonctionne manuellement mais échoue au démarrage, vous avez probablement un /etc/crypttab cassé ou un initramfs manquant les hooks cryptsetup ou le matériel de clé. Planifiez de corriger et de reconstruire initramfs depuis un chroot.

Task 12: Check filesystem health when mount fails

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
mount: mounting /dev/vda2 on /mnt failed: Structure needs cleaning
cr0x@server:~$ fsck.ext4 -fy /dev/vda2
e2fsck 1.47.1 (20-May-2024)
/dev/vda2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vda2: 245321/2621440 files (0.3% non-contiguous), 1987654/10485760 blocks

Ce que ça signifie : « Structure needs cleaning » indique une corruption du système de fichiers qui empêchait le montage. fsck a réparé quelque chose.

Décision : Retentez le montage en lecture seule, puis poursuivez. Si la corruption se reproduit, suspectez un matériel défaillant ou des problèmes de périphérique sous-jacents (SMART, erreurs du contrôleur), et prévoyez un remplacement.

Task 13: If you can mount root, collect the real boot logs

cr0x@server:~$ mount -o ro /dev/vda2 /mnt
cr0x@server:~$ grep -R "ALERT!" -n /mnt/var/log | head
/mnt/var/log/boot.log:37:ALERT! /dev/disk/by-uuid/4b3f0f2e-9b7b-4c4a-8f1a-2bd4e7e1f6b1 does not exist. Dropping to a shell!

Ce que ça signifie : Le système installé a déjà enregistré l’échec plus tôt. C’est généralement une incohérence d’identifiant ou une couche manquante.

Décision : Utilisez la chaîne d’erreur exacte pour orienter la correction. Ne « optimisez » pas. Réparez ce qui est nommé.

Task 14: Prepare a chroot for durable fixes (from initramfs or rescue)

cr0x@server:~$ mount /dev/vda2 /mnt
cr0x@server:~$ mount /dev/vda1 /mnt/boot/efi
cr0x@server:~$ mount -t proc proc /mnt/proc
cr0x@server:~$ mount -t sysfs sys /mnt/sys
cr0x@server:~$ mount -o bind /dev /mnt/dev
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# cat /etc/debian_version
trixie/sid

Ce que ça signifie : Vous opérez maintenant dans le système installé, avec accès aux outils de paquetage et à la configuration au bon endroit.

Décision : Reconstruisez initramfs et mettez à jour GRUB depuis ici afin que les modifications persistent au redémarrage.

Task 15: Rebuild initramfs properly (and for the kernel you boot)

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# ls /boot
System.map-6.12.0-1-amd64  config-6.12.0-1-amd64  initrd.img-6.12.0-1-amd64  vmlinuz-6.12.0-1-amd64  efi
cr0x@server:/# update-initramfs -u -k 6.12.0-1-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

Ce que ça signifie : Debian a régénéré l’image initramfs pour ce noyau spécifique.

Décision : Si vous avez modifié crypttab, mdadm, lvm ou les modules, cette étape est non négociable. Si plusieurs noyaux sont installés, envisagez -k all pour éviter de booter une ancienne image cassée plus tard.

Task 16: Update GRUB so root= matches reality

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done
cr0x@server:/# grub-install /dev/vda
Installing for x86_64-efi platform.
Installation finished. No error reported.

Ce que ça signifie : La configuration GRUB a été régénérée ; GRUB a été installé sur la bonne cible (UEFI ici). Sur les systèmes BIOS vous verriez i386-pc et un embedding MBR/BIOS.

Décision : Lancez grub-install seulement si nécessaire (disque remplacé, entrées EFI cassées, chargeur manquant). Sinon update-grub suffit généralement et est moins risqué.

Task 17: Verify the identifiers referenced by fstab are resolvable

cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# findmnt --verify --verbose
Success, no errors or warnings detected

Ce que ça signifie : Votre configuration de montage est cohérente en interne. Cela ne garantit pas que le matériel fonctionne, mais cela élimine les pièges évidents.

Décision : Si findmnt --verify se plaint, corrigez ces entrées avant de redémarrer. Ne remettez pas un système « qui démarre mais dont les montages sont cassés » en production.

Trois mini-récits d’entreprise depuis le terrain

Incident #1 : La panne causée par une mauvaise hypothèse (les noms de périphériques sont stables)

Une entreprise de taille moyenne faisait tourner Debian sur une flotte d’hôtes de virtualisation sur site. Les partitions root étaient référencées dans GRUB et /etc/fstab sous la forme /dev/sda2. « Ça marchait depuis des années », et c’est ainsi que la dette technique vous apprend à baisser la garde.

Ils ont ajouté un nouveau HBA pour étendre le stockage. Après un redémarrage de maintenance, deux hôtes sont tombés dans initramfs. Les disques allaient bien. L’OS n’allait pas bien. Le nouveau contrôleur a changé l’ordre de découverte, et l’ancien /dev/sda est devenu /dev/sdb. Le système a essayé de monter la mauvaise partition comme root ; initramfs s’est arrêté, refusant correctement de continuer avec des absurdités.

Le premier intervenant a fait ce que beaucoup font sous pression : il a commencé à éditer les entrées GRUB à la main à la console, en remplaçant sda2 par sdb2. Ça a démarré. Ils l’ont répété sur le deuxième hôte. Tout le monde s’est détendu.

Puis au reboot suivant l’ordre des périphériques a tourné à nouveau sur un hôte, et il a échoué de nouveau. C’est alors qu’ils ont fait la correction ennuyeuse : convertir les références root en UUID, régénérer la config GRUB, reconstruire initramfs, et standardiser la flotte.

La leçon n’était pas « ne pas ajouter de HBA ». C’était : traitez les noms /dev/sdX comme éphémères dans tout ce qui doit survivre à un reboot. Linux ne vous promettra pas un alphabet stable.

Incident #2 : L’optimisation qui s’est retournée contre eux (un « initramfs mince » qui ne pouvait pas démarrer)

Une équipe SaaS voulait des temps de boot plus rapides pour des nœuds autoscalés. Quelqu’un a proposé d’alléger le contenu d’initramfs : moins de modules, moins de hooks, image plus petite, décompression plus rapide. Idée raisonnable — jusqu’à ce que vous vous rappeliez que le démarrage précoce est l’endroit où la réalité se vérifie.

Ils ont personnalisé la génération d’initramfs pour omettre ce qui « n’était pas nécessaire ». Ça a fonctionné en staging, parce que staging utilisait un seul profil de stockage : disques virtio, pas de chiffrement, pas de RAID. La production avait des profils mélangés : certains nœuds bootaient depuis NVMe, d’autres depuis SATA, certains avaient LUKS pour une exception de conformité, et quelques-uns étaient encore sur md RAID parce que le cluster avait démarré ainsi des années plus tôt.

Pendant un déploiement de noyau, un sous-ensemble de nœuds a commencé à tomber dans initramfs. L’initramfs n’incluait plus le module NVMe sur certaines images, et les hooks cryptsetup sur d’autres. Ils n’étaient pas des « serveurs cassés ». Ils exécutaient fidèlement les artefacts de démarrage qu’on leur avait fournis.

La correction n’a pas été d’ajouter « rootdelay » et d’espérer. Ils ont annulé l’allègement, reconstruit initramfs avec les hooks appropriés, puis introduit une matrice contrôlée : une image par profil de stockage. Ils ont aussi ajouté une porte pré-reboot : valider qu’initramfs contient les modules requis pour la plateforme.

L’optimisation n’a pas économisé de temps. Elle a déplacé le temps du « chemin de boot » vers la « réponse à incident », qui est le calcul le plus coûteux que vous puissiez acheter : l’attention humaine à 2h du matin.

Incident #3 : La pratique ennuyeuse qui a sauvé la mise (récupération documentée + identifiants cohérents)

Une organisation financière faisait tourner Debian sur des serveurs de bases de données avec root chiffré et LVM. L’environnement était ennuyeux, au sens positif : partitionnement cohérent, montages basés sur UUID, et une procédure standard pour les « échecs de boot ». Cela existait parce que quelqu’un avait déjà payé le prix du chaos une fois.

Un matin, un incident électrique a coupé un rack. Après le rétablissement du courant, plusieurs serveurs sont restés sur initramfs avec des messages sur un système de fichiers non propre et des périphériques retardés. Personne n’a paniqué parce qu’ils avaient un playbook et le testaient trimestriellement.

Le responsable a appliqué les étapes : vérifier la découverte des périphériques, déverrouiller LUKS manuellement, activer LVM, monter root en lecture seule, exécuter un fsck si nécessaire, puis chroot et reconstruire initramfs juste pour s’assurer que les hooks étaient corrects. Ils ont aussi vérifié les compteurs SMART avant de déclarer victoire.

Le résultat n’était pas glamour. Pas de hacks héroïques. Juste une récupération prévisible et un rapport post-incident propre : le stockage était revenu lentement, quelques systèmes de fichiers avaient besoin de récupération du journal, et la chaîne de démarrage a fait exactement ce pour quoi elle a été conçue — s’arrêter avant d’endommager davantage les données.

Blague #2 : Les systèmes les plus fiables sont construits sur des habitudes ennuyeuses, ce qui explique pourquoi ils sont rarement invités aux réunions excitantes.

Erreurs courantes (symptôme → cause → fix)

C’est là que vivent la plupart des tickets « initramfs pour toujours » : pas dans des bugs noyau profonds, mais dans la dérive prévisible de configuration. Utilisez cette section comme une table de consultation.

« ALERT! /dev/disk/by-uuid/… does not exist » → UUID erroné → mettre à jour les identifiants et reconstruire

Symptôme : initramfs affiche une ALERT sur un UUID manquant et vous laisse dans un shell.
Cause : L’UUID du système de fichiers a changé (clone/restore/reformat) ou la config pointe vers un ancien disque.
Fix : Utilisez blkid pour trouver les vrais UUID ; mettez à jour /etc/fstab et la config GRUB ; exécutez update-initramfs et update-grub.

« Gave up waiting for root device » → le périphérique apparaît tard ou jamais → ajouter le pilote, corriger les modules, ou ajouter un délai

Symptôme : Messages sur l’attente du root, puis échec.
Cause : Module de contrôleur manquant dans initramfs, ou découverte du stockage lente (USB/NVMe derrière un firmware étrange).
Fix : Assurez-vous que le module est inclus (installez les paquets appropriés, ajoutez à /etc/initramfs-tools/modules), reconstruisez initramfs. Seulement si le matériel est lent mais correct, ajoutez temporairement rootdelay=10.

« Volume group not found » → outils/hooks LVM manquants → inclure lvm2 dans initramfs

Symptôme : Pas de /dev/vg0/root, vgscan échoue ou n’est pas présent.
Cause : lvm2 non installé ou non inclus dans initramfs ; ou filtre erroné dans la config LVM.
Fix : Depuis le chroot : installez/réparez lvm2, exécutez update-initramfs -u -k all. Évitez le sur-filtrage des périphériques sauf si vous savez pourquoi.

« Cannot unlock /dev/… (cryptsetup: not found) » → cryptsetup manquant → reconstruire initramfs avec cryptsetup

Symptôme : Pas d’invite de mot de passe, ou erreurs cryptsetup.
Cause : paquet/hooks cryptsetup manquants dans initramfs, ou /etc/crypttab cassé.
Fix : Corrigez /etc/crypttab, assurez-vous que cryptsetup-initramfs est installé, reconstruisez initramfs.

« md0 stopped/does not exist » → RAID non assemblé → corriger mdadm et initramfs

Symptôme : Ensembles absents dans /proc/mdstat.
Cause : config mdadm non intégrée à initramfs, UUID d’ensemble changé, ou noms de périphériques modifiés.
Fix : Assemblez manuellement pour prouver que ça marche ; mettez à jour /etc/mdadm/mdadm.conf ; reconstruisez initramfs.

« Structure needs cleaning » ou erreur de montage → corruption du système de fichiers → fsck/xfs_repair puis vérifier la santé du disque

Symptôme : montage échoue ; fsck rapporte des réparations.
Cause : arrêt non propre, erreurs I/O sous-jacentes, ou défaillance réelle du média.
Fix : Lancez l’outil de réparation adapté ; puis vérifiez SMART et les logs noyau pour des erreurs I/O. Si les erreurs persistent, ne faites plus confiance à ce disque.

Démarrage réussi une seule fois après des edits manuels → vous avez corrigé un symptôme, pas le système → rendre les changements persistants

Symptôme : Éditer GRUB au boot vous fait entrer, mais un reboot casse à nouveau.
Cause : Vous n’avez pas régénéré la config GRUB ou initramfs dans le système installé.
Fix : Montez root, chroot, appliquez les changements dans /etc/default/grub, /etc/fstab, /etc/crypttab, puis update-grub et update-initramfs.

Checklists / step-by-step plan (get back to green)

Checklist A: Minimal steps to boot once (triage mode)

Au shell initramfs, exécutez cat /proc/cmdline et notez ce que root est censé être.
Exécutez lsblk et blkid pour voir ce qui existe.
Si root est chiffré : cryptsetup luksOpen.
Si root est LVM : vgscan puis vgchange -ay.
Si root est RAID : mdadm --assemble --scan.
Montez root en lecture seule ; inspectez /etc/fstab et /var/log/boot.log pour des erreurs explicites.
Si le montage échoue : exécutez l’outil de réparation du système de fichiers approprié.
Redémarrez seulement après avoir rendu les identifiants cohérents, sinon vous retomberez dans la boucle.

Checklist B: Durable repair steps (the ones that stop recurrence)

Montez root et (si applicable) la partition système EFI sur /boot/efi.
Bind-montez /dev, montez /proc et /sys, puis chroot.
Corrigez /etc/fstab pour utiliser les UUID/PARTUUID corrects (privilégiez UUID pour les systèmes de fichiers, PARTUUID pour les partitions dans certains setups de boot).
Corrigez /etc/crypttab et /etc/mdadm/mdadm.conf si utilisés.
Régénérez initramfs pour tous les noyaux installés : update-initramfs -u -k all.
Régénérez la config GRUB : update-grub.
Installez GRUB seulement si le chargeur lui-même est endommagé ou si les entrées disque/EFI ont changé : grub-install ....
Exécutez findmnt --verify --verbose pour valider les montages.
Redémarrez et surveillez la console une fois. Si c’est un serveur distant, gardez une console hors bande attachée pour le premier reboot.

Checklist C: If the initramfs doesn’t have the tools you need

Bootez depuis un ISO d’installeur/de secours Debian ou un environnement live.
Montez le système root sous /mnt (plus l’EFI si nécessaire).
Chroot et installez les paquets manquants : lvm2, mdadm, cryptsetup-initramfs selon les besoins.
Reconstruisez initramfs et GRUB depuis le chroot.

FAQ

1) Est-ce qu’initramfs signifie que mon installation est corrompue ?

Non. Cela signifie que le boot précoce ne peut pas monter root. Cela peut être de la corruption, mais c’est plus souvent un périphérique manquant, un UUID erroné, ou une couche de stockage non assemblée.

2) Je vois mon disque dans `lsblk`. Pourquoi ne peut-il pas monter root ?

Parce que « le disque existe » n’est pas la même chose que « l’identifiant root correspond » ou « les couches sont assemblées ». Comparez les UUID avec blkid. Si chiffrement/LVM/RAID est utilisé, root peut être à l’intérieur d’un périphérique mappé qui n’existe pas encore.

3) Dois-je ajouter `rootdelay=` pour corriger ça ?

Seulement si le périphérique apparaît tard mais de façon consistante (commun avec certains boots USB ou firmware bizarres). Si l’UUID est faux ou que le pilote manque, rootdelay ne fait que vous faire attendre plus longtemps pour la même panne.

4) Pourquoi cela est-il arrivé juste après une mise à jour du noyau ?

Les mises à jour du noyau régénèrent souvent initramfs. Si des hooks manquent, la config a changé, ou vous bootez sur un noyau différent de celui que vous croyez, le nouvel initramfs peut ne pas inclure les modules/outils dont votre pile root a besoin.

5) J’ai édité GRUB au boot et ça a marché. Comment rendre ça permanent ?

Boot, montez, chroot, corrigez /etc/default/grub ou les références UUID sous-jacentes, puis exécutez update-grub. Si initramfs doit aussi être modifié, exécutez update-initramfs -u -k all.

6) Puis-je revenir aux références style `/dev/sda2` ?

Vous pouvez, mais vous choisissez la fragilité. Les identifiants stables existent parce que l’énumération des périphériques n’est pas stable. Utilisez UUID/PARTUUID sauf si vous aimez la roulette du boot.

7) Quelle est la différence entre corriger `/etc/fstab` et corriger le `root=` de GRUB ?

Le root= de GRUB contrôle ce qui est monté comme / pendant le boot précoce. /etc/fstab contrôle ce qui est monté après le démarrage du vrai userspace. Si l’un ou l’autre est faux, vous pouvez échouer — simplement à des moments différents.

8) Est-il sûr d’exécuter la réparation du système de fichiers depuis initramfs ?

C’est souvent l’endroit le plus sûr car moins de choses sont montées. Néanmoins : exécutez uniquement l’outil adapté à votre système de fichiers, et privilégiez d’abord les montages en lecture seule et le diagnostic. Si vous suspectez une défaillance matérielle, les réparations peuvent ne pas « tenir ».

9) Mon shell initramfs n’a pas `lvm` ou `mdadm`. Et maintenant ?

Bootez un environnement de secours, montez le système, chrootez, installez les paquets manquants, puis reconstruisez initramfs. Si les outils ne sont pas dans initramfs, il ne pourra pas assembler votre pile de stockage au démarrage.

10) Comment savoir si c’est du matériel ?

Cherchez des erreurs I/O dans dmesg, des corruptions répétées de systèmes de fichiers, des périphériques qui disparaissent, ou des échecs SMART (depuis un environnement de secours). Les problèmes de configuration échouent généralement de façon consistante ; le matériel échoue de façon créative.

Étapes suivantes pour éviter les incidents répétés

Le prompt initramfs est un symptôme, pas un diagnostic. Il vous dit une chose : « root n’a pas été monté ». Votre travail est de répondre au pourquoi avec des preuves : périphériques bloc, identifiants, et assemblage des couches de stockage.

Faites ceci ensuite, dans cet ordre :

Rendez les identifiants cohérents. Alignez root=, /etc/fstab, et toutes les configs de couche (crypttab, mdadm, LVM) avec ce que blkid rapporte.
Reconstruisez initramfs pour tous les noyaux que vous pourriez booter. Si vous ne corrigez que le noyau en cours, un reboot ultérieur peut démarrer sur une image ancienne et cassée.
Régénérez la config GRUB. Puis installez GRUB seulement si nécessaire.
Standardisez et documentez. Si vous gérez plus d’un système, verrouillez une pile root cohérente (UUIDs, même partitionnement, même chiffrement/LVM/RAID) et gardez une checklist de récupération testée, pas admirée.

Une citation à garder en tête pendant ces incidents : « L’espoir n’est pas une stratégie. » (idée paraphrasée, souvent répétée dans les cercles ingénierie/ops)

Quand tout sera de nouveau opérationnel, considérez l’incident comme un cadeau : il vous a montré exactement où votre chaîne de démarrage dépend du savoir tribal. Corrigez cette dépendance. Votre vous futur en sera moins fatigué.