Pourquoi mon serveur tombe en kernel panic avec « ALERT! UUID=... does not exist. Dropping to a shell! » au boot ?

Le kernel a chargé l’initrd mais ne trouve pas le rootfs : l’UUID pointe vers un filesystem ext4 situé sur un volume RAID (md0) qui n’a pas encore été assemblé. Vérifiez si mdadm est bien présent dans l’initrd avec lsinitramfs /boot/initrd.img-* | grep mdadm ; s’il est absent, l’array RAID ne peut pas être monté au boot.

Pourquoi mdadm n’est pas dans mon initrd alors que mon système utilise un RAID ?

Debian n’embarque mdadm dans l’initrd que si la clé d’installation avait elle-même un RAID configuré. Si vous avez chargé le kernel depuis une clé sans RAID, mdadm n’a pas été inclus. Installez-le avec apt install mdadm, ce qui déclenche automatiquement update-initramfs et ajoute les scripts local-block/mdadm et local-bottom/mdadm.

Comment laisser le temps à mdadm d’assembler le RAID avant le montage du rootfs ?

Ajoutez rootdelay=N à GRUB_CMDLINE_LINUX dans /etc/default/grub puis lancez update-grub. Sans ce délai l’initrd cherche le rootfs immédiatement et abandonne après le timeout (« Gave up waiting for root device »). Comptez rootdelay=15 pour un matériel lent type Atom + USB-IDE, et environ 5s pour du NVMe moderne.

Comment forcer Debian à booter sur un RAID1 dégradé (un seul disque sur deux) ?

Par défaut Debian refuse de booter un RAID dégradé. Créez le fichier /etc/initramfs-tools/conf.d/mdraid contenant BOOT_DEGRADED=true, puis régénérez l’initrd avec update-initramfs -u. Astuce : testez le boot en QEMU avec l’option snapshot=on avant de redémarrer le matériel pour voir où ça bloque sans console série.

Booter un RAID1 dégradé : `rootdelay` + mdadm dans l’initrd

Mon NAS Netgear migré vers Debian a un RAID1 dégradé (un seul disque physique sur deux). Dans /etc/default/grub :

GRUB_CMDLINE_LINUX="... root=UUID=a4aae2bb-...-0651084e9642"

Au reboot, kernel panic :

ALERT! UUID=a4aae2bb... does not exist. Dropping to a shell!

Le kernel charge. L’initrd démarre. Mais ne trouve pas le rootfs.

Diagnostic

L’UUID est celui du filesystem ext4 sur md0, le RAID1. Pour que le kernel le voie :

mdadm dans l’initrd pour assembler md0 depuis /dev/sda2
Timing correct : le disque SATA peut être lent à apparaître (Atom + USB-IDE = 3-5s)

$ lsinitramfs /boot/initrd.img-6.1.0-* | grep mdadm
# (vide → mdadm absent !)

mdadm n’est pas dans l’initrd parce que la clé Debian dont on a chargé le kernel n’avait pas mdadm installé. La clé n’avait pas de RAID, donc Debian ne l’a pas embarqué.

Solution

1. Installer mdadm + regénérer l’initrd

apt install mdadm   # update-initramfs auto-déclenché
lsinitramfs /boot/initrd.img-* | grep mdadm
# scripts/local-block/mdadm
# scripts/local-bottom/mdadm

2. Ajouter `rootdelay=N`

Sans ça, l’initrd cherche le rootfs immédiatement après résolution des UUIDs :

Begin: Waiting for root file system ... 
... timeout (30s) ...
Gave up waiting for root device.

Avec rootdelay=15, l’initrd attend 15s, laissant le temps à mdadm d’assembler l’array.

GRUB_CMDLINE_LINUX="... root=UUID=a4aae2bb-... rootdelay=15"
update-grub

3. Bonus : forcer le RAID dégradé à monter

Par défaut Debian considère un RAID dégradé comme « ne pas booter » :

# /etc/initramfs-tools/conf.d/mdraid
BOOT_DEGRADED=true

Puis update-initramfs -u.

Pourquoi `rootdelay` plutôt qu’autre chose

systemd a udev qui détecte dynamiquement les nouveaux block devices. Mais c’est dans l’initrd que ça se joue, et l’initrd Debian est en scripts shell, pas systemd. Mode polling, rootdelay est le plus simple. Alternative dracut : rd.retry=N rd.timeout=N — mais Debian utilise initramfs-tools.

Lessons learned

mdadm n’est pas dans l’initrd par défaut. apt install mdadm déclenche update-initramfs.
rootdelay=15 pour Atom + USB-IDE. NVMe moderne : 5s suffit.
Tester en QEMU avant de redémarrer hardware : qemu-system-x86_64 -drive file=/dev/sda,format=raw,snapshot=on -nographic -serial mon:stdio voit où ça bloque sans console série.
lsinitramfs | grep <module> est plus fiable que dpkg -l : le package peut être installé mais pas dans l’initrd.