Debian 13 : votre serveur ne démarre plus après des mises à jour — le rollback propre de GRUB qui fonctionne vraiment

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

Cet article vous a aidé ?

Votre fenêtre de maintenance s’est terminée il y a 20 minutes. Le serveur est toujours « down ». La console hyperviseur affiche une petite invite polie grub rescue> qui se moque de votre SLA. Et quelqu’un sur Slack tape « did we brick it? » avec la confiance d’une personne qui n’a jamais dû débriquer quoi que ce soit.

Voici le chemin de récupération qui marche dans le monde réel : diagnostic rapide d’abord, puis rollback/réinstallation propre de GRUB sans transformer votre disque en scène de crime, puis hygiène du noyau/initramfs et de /boot pour que ça ne se reproduise pas.

Playbook de diagnostic rapide (quoi vérifier en 1er/2e/3e)

Les pannes de démarrage après des mises à jour sont rarement « mystiques ». Elles appartiennent généralement à quatre catégories : mauvais périphérique/entrée EFI, core/config de GRUB cassé, noyau/initramfs manquant, ou échecs d’ouverture/assemblage du stockage (LUKS/RAID/ZFS). Votre rôle est d’identifier la catégorie en quelques minutes, pas en heures.

Premier point : identifiez l’étape de la panne par l’écran exact

L’écran du firmware UEFI revient au menu BIOS/UEFI : le firmware ne trouve pas d’entrée de démarrage ou le binaire EFI est manquant/inaccessible.
grub rescue> : GRUB s’est chargé mais ne trouve pas ses modules ou sa configuration ; souvent le prefix pointe au mauvais endroit ou le système de fichiers a été déplacé.
grub> (invite complète) : GRUB est fonctionnel ; il peut probablement charger un noyau si vous le pointez vers la bonne partition.
Le noyau se charge puis tombe dans initramfs : l’initramfs ne trouve pas la racine (mauvais UUID, pilote manquant, invite LUKS absente, mdraid qui ne s’assemble pas).
Kernel panic immédiatement après la mise à jour : noyau incorrect, initramfs cassé, ou un pilote/régression ; revenir à un noyau antérieur est généralement le plus rapide.

Deuxième point : collectez un fait solide : quel disque et quel mode de démarrage

Avant de « corriger », décidez : UEFI ou BIOS hérité ? NVMe ou SATA ? mdraid/LUKS/ZFS ? Si vous devinez, vous vous tromperez sous pression.

Troisième point : choisissez la voie de récupération la moins risquée

Si vous atteignez le menu GRUB : démarrez d’abord un noyau plus ancien. C’est le rollback le moins invasif.
Si vous atteignez un environnement de secours : montez, chrootez, réinstallez GRUB proprement, régénérez l’initramfs, vérifiez l’espace de /boot.
Si les disques ne s’assemblent/pas ne se déverrouillent : réparez mdadm/LUKS d’abord ; réinstaller GRUB sur un disque que le système ne peut pas lire, c’est de l’art performance.

Règle opérationnelle : n’écrivez pas sur les disques tant que vous ne pouvez pas expliquer ce que vous écrivez et où les octets vont. La façon la plus rapide de transformer un incident de démarrage en incident de récupération de données est de « simplement lancer grub-install partout ».

Pourquoi Debian « ne démarre plus après des mises à jour » arrive (et ce qui est réellement cassé)

Les mises à jour Debian touchent des éléments critiques du démarrage d’une manière à la fois robuste et impitoyable. Les paquets font la bonne chose la plupart du temps — jusqu’à ce que votre configuration soit légèrement inhabituelle, que votre /boot manque d’espace, que votre firmware soit capricieux, ou que vous utilisiez des piles de stockage qui nécessitent une coopération en early userspace.

Déclencheurs courants :

Mise à jour du paquet GRUB qui a écrit de nouveaux fichiers core mais votre partition système EFI (ESP) n’était pas montée. La mise à jour « réussit » et pourtant le firmware continue de démarrer un ancien binaire.
/boot rempli donc la génération du noyau ou de l’initramfs a été partielle. Vous avez maintenant une entrée de menu GRUB pointant vers un noyau qui existe, mais l’initramfs est manquant — ou l’inverse.
Les ID/UUID des disques ont changé (clonage, remplacement de disque, reshaping RAID). La config GRUB référence d’anciens UUID, donc il ne trouve pas /boot/grub ou le noyau.
Les entrées NVRAM UEFI ont été réinitialisées (mise à jour du firmware, reset CMOS, firmware du vendeur capricieux). Le disque est intact ; le firmware a oublié comment le trouver.
Initramfs a perdu un pilote ou un hook nécessaire (surtout avec mdraid, LUKS, HBAs exotiques, ou ZFS-on-root). Le noyau se charge, puis l’early userspace ne parvient pas à localiser la racine.
Interactions Secure Boot : shim, GRUB signé, ou signatures de noyau ne correspondant pas à ce que le firmware attend. Les symptômes vont d’un refus silencieux à un court flash et un reboot.

Si vous cherchez un coupable unique, ce n’est généralement pas « GRUB est mauvais ». C’est « la chaîne de garde des artefacts de démarrage est désordonnée ». Votre rollback doit restaurer la chaîne, pas ajouter des copies aléatoires de grubx64.efi dans des endroits surprenants.

Faits intéressants et un peu d’histoire du chargeur de démarrage

Le nom GRUB est littéral : il a commencé comme « GRand Unified Bootloader » dans le projet GNU, destiné à unifier le chaos des premiers gestionnaires de démarrage PC.
GRUB de l’ère BIOS utilisait un chargement en plusieurs étapes (stage1 dans le MBR, stage1.5 dans le « gap MBR », stage2 dans /boot). Les disques GPT et les outils modernes ont rendu le « gap » peu fiable, poussant à utiliser des partitions BIOS Boot.
UEFI a changé la donne : les chargeurs de démarrage sont devenus des fichiers normaux sur une ESP formatée en FAT, ce qui est à la fois plus simple et plus fragile (facile à écraser, facile à oublier de monter).
Le chemin « fallback » UEFI existe pour une raison : \EFI\BOOT\BOOTX64.EFI est le chemin par défaut que beaucoup de firmwares essaient quand les entrées NVRAM sont manquantes ou corrompues.
Le packaging du noyau Debian est conservateur comparé à certaines distributions : les anciens noyaux restent par conception, d’où la possibilité de revenir à un noyau antérieur via le menu — sauf si /boot a manqué d’espace.
Initramfs n’est pas du théâtre optionnel : pour les racines chiffrées, le RAID, ou de nombreux pilotes de stockage, c’est l’early userspace qui assemble l’environnement avant que /sbin/init n’ait sa chance.
« update-grub » est un wrapper convivial autour de grub-mkconfig. L’important est la config générée et les modules que GRUB peut réellement charger.
La NVRAM UEFI est finie et les implémentations firmware des vendeurs varient énormément. Les systèmes peuvent et font « oublier » des entrées de démarrage lors de mises à jour de firmware ou quand la NVRAM est pleine.

Une citation pour garder les pieds sur terre, attribuée à Werner Vogels : « Everything fails, all the time. » Ce n’est pas du nihilisme ; c’est une exigence de conception.

Triage depuis la console : types d’écrans GRUB et leur signification

Cas A : « No bootable device » ou le firmware bascule dans les paramètres

Cela signifie généralement que le firmware ne trouve pas le chargeur EFI (UEFI) ou qu’il manque le code de démarrage (BIOS hérité). L’OS peut être intact. Votre travail est de restaurer un chemin de démarrage valide.

Cas B : `grub rescue>`

GRUB fonctionne en mode réduit. Il ne trouve pas ses modules/config habituels. Causes typiques : mauvais prefix, partitions déplacées, /boot/grub manquant, ou système de fichiers que GRUB ne peut pas lire (moins courant sur les valeurs par défaut Debian, plus courant avec des fichiers exotiques).

Cas C : le menu GRUB apparaît, le noyau se charge, puis vous atterrissez dans initramfs

GRUB a fait son travail. Maintenant, l’initramfs ne peut pas monter le système racine. Raisons courantes : mauvais UUID racine dans la ligne de commande du noyau, assemblage mdraid manquant, périphérique LUKS non déverrouillé, module pilote absent, ou régression. Cela ressemble souvent à « Debian ne démarre pas » mais GRUB est innocent.

Blague #1 : GRUB est comme un videur : il a l’air effrayant, mais la plupart du temps il n’applique que la liste que vous lui avez donnée.

Le rollback propre de GRUB qui fonctionne vraiment

« Rollback » dans le monde des chargeurs n’est pas un bouton unique. Ce que vous voulez, c’est un ensemble connu et sain d’artefacts de démarrage : un binaire GRUB que votre firmware peut charger, des modules GRUB là où GRUB les attend, et une config qui pointe vers des noyaux et initramfs réels. Vous pouvez y arriver de deux manières propres :

Rollback doux (préféré quand possible) : démarrez un noyau plus ancien depuis le menu « Advanced options » de GRUB. Puis reconstruisez l’initramfs et la config GRUB dans le système en cours d’exécution, et seulement ensuite réinstallez le chargeur si nécessaire.
Rollback dur (quand rien ne démarre) : démarrez un environnement de secours, montez les systèmes de fichiers, chrootez, réinstallez GRUB proprement sur la cible correcte (UEFI ou BIOS), régénérez initramfs et la config GRUB, vérifiez les entrées EFI.

Ce qu’il faut éviter : copier des binaires EFI au hasard sans comprendre lequel le firmware utilise, réinstaller GRUB sur tous les disques « au cas où », ou éditer grub.cfg à la main comme si c’était 2004. Debian l’écrasera plus tard, et vous l’oublierez, et votre futur vous méritera mieux.

Choix de l’environnement de récupération

Utilisez ce qui est le plus proche du système : un installateur Debian en mode rescue, une image live, ou le système de secours distant du datacenter. L’essentiel est que vous puissiez monter le système racine installé et lancer les outils Debian depuis ce chroot.

Décider du mode de démarrage : UEFI vs BIOS

N’assumez pas. Beaucoup de serveurs supportent les deux, et un reset firmware peut basculer la préférence. Debian peut être installé dans l’un ou l’autre mode. Votre réinstallation doit correspondre au mode.

Ce que « propre » signifie pour GRUB

UEFI : l’ESP correcte est montée sur /boot/efi dans le chroot, vous installez grub-efi-amd64 (ou équivalent arm64), vous lancez grub-install une seule fois vers le bon --efi-directory, et vous confirmez l’entrée NVRAM (ou le fichier fallback) existe.
BIOS : vous installez grub-pc, vous lancez grub-install /dev/sdX sur le(s) disque(s) correct(s), pas sur des partitions, et vous vérifiez l’existence d’une BIOS Boot Partition sur GPT si nécessaire.

Tâches pratiques : commandes, sortie attendue, et la décision que vous prenez

Voici les tâches que vous exécutez réellement sous pression. Chacune inclut : la commande, ce que signifie la sortie, et la décision suivante.

Task 1: Confirm whether you’re booted in UEFI mode (in rescue/live)

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Dec 28 10:11 /sys/firmware/efi

Signification : le répertoire existe → vous êtes actuellement démarré en mode UEFI. S’il manque, vous êtes en mode BIOS hérité/CSM.

Décision : faites correspondre le mode du système installé. Si le serveur a été installé en UEFI mais que votre rescue a démarré en BIOS, réinstaller GRUB en UEFI peut échouer ou installer la mauvaise chose.

Task 2: Inventory disks/partitions and spot the ESP and /boot

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,FSVER,LABEL,PARTLABEL,PARTUUID,MOUNTPOINTS
NAME        SIZE FSTYPE FSVER LABEL PARTLABEL        PARTUUID                             MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   FAT32       EFI System     7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e
├─nvme0n1p2     2G ext4         boot  Linux filesystem 1b2c3d4e-...                      
└─nvme0n1p3 951.4G crypto_LUKS        luks  Linux filesystem 9a8b7c6d-...

Signification : repérez vfat avec « EFI System » → c’est votre ESP. Repérez ext4 étiqueté boot → probablement /boot.

Décision : vous savez maintenant quoi monter où. Si vous ne voyez pas d’ESP sur un système UEFI, vous regardez peut‑être le mauvais disque ou l’ESP est manquante/corrompue.

Task 3: If using LUKS, unlock root (or the container that contains root)

cr0x@server:~$ cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:

cr0x@server:~$ ls /dev/mapper/cryptroot
/dev/mapper/cryptroot

Signification : le mapping existe → le bloc déchiffré est disponible.

Décision : montez le LVM ou les systèmes de fichiers à l’intérieur. Si le déverrouillage échoue, arrêtez et corrigez les clés/TPM/les invites d’abord — le travail sur le chargeur de démarrage n’aidera pas.

Task 4: If using LVM inside LUKS, activate volume groups

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

Signification : les LV sont actifs et apparaîtront sous /dev/vg0/....

Décision : montez le LV racine. Si les VGs n’apparaissent pas, il se peut que les bons nœuds device-mapper manquent, ou que vous ayez déverrouillé le mauvais conteneur.

Task 5: Mount the installed system (root, /boot, ESP) correctly

cr0x@server:~$ mount /dev/vg0/root /mnt
cr0x@server:~$ mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ findmnt -R /mnt
TARGET        SOURCE           FSTYPE OPTIONS
/mnt          /dev/vg0/root    ext4   rw,relatime
/mnt/boot     /dev/nvme0n1p2   ext4   rw,relatime
/mnt/boot/efi /dev/nvme0n1p1   vfat   rw,relatime,fmask=0022,dmask=0022

Signification : tous les points de montage attendus sont présents. C’est là que beaucoup de tentatives de « réinstaller GRUB » échouent : l’ESP n’était pas montée, donc le nouveau binaire EFI a été placé dans un répertoire sur le système racine, pas sur la FAT lisible par le firmware.

Décision : si /mnt/boot/efi n’est pas vfat, corrigez vos montages avant de toucher à GRUB.

Task 6: Bind-mount runtime filesystems and chroot

cr0x@server:~$ mount --bind /dev /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
root@server:/#

Signification : vous opérez maintenant comme si vous aviez démarré dans l’OS installé, en utilisant ses paquets et configurations.

Décision : toute remédiation doit maintenant utiliser les outils Debian depuis ce chroot.

Task 7: Check for a half-configured dpkg state (common after interrupted updates)

root@server:/# dpkg --audit
The following packages are only half configured, probably due to problems configuring them the first time.
 grub-efi-amd64
 linux-image-6.12.0-amd64

Signification : l’état du packaging est incohérent. Cela peut laisser des fichiers GRUB manquants ou des artefacts de noyau incomplets.

Décision : exécutez les étapes de récupération de dpkg avant de réinstaller le chargeur.

Task 8: Finish interrupted package configuration cleanly

root@server:/# apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-6.12.0-amd64 (6.12.18-1) ...
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64
Setting up grub-efi-amd64 (2.12-5) ...

Signification : la génération d’initramfs et la configuration du paquet GRUB se sont exécutées. Surveillez les erreurs concernant le remplissage de /boot ou l’ESP non montée.

Décision : si des erreurs apparaissent, corrigez-les immédiatement (espace, montages) avant de continuer.

Task 9: Check `/boot` space (this one bites constantly)

root@server:/# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  2.0G  1.9G   42M  98% /boot

Signification : /boot est effectivement plein. Les mises à jour du noyau peuvent avoir laissé des images partielles ou refusé d’installer de nouvelles correctement.

Décision : supprimez proprement les anciens noyaux (pas en supprimant des fichiers au hasard) avant de régénérer initramfs/la config GRUB.

Task 10: List installed kernels and remove stale ones safely

root@server:/# dpkg -l 'linux-image-*' | awk '/^ii/ {print $2 "\t" $3}'
linux-image-6.10.0-amd64	6.10.12-1
linux-image-6.12.0-amd64	6.12.18-1
linux-image-amd64	6.12.18-1

root@server:/# apt-get remove --purge linux-image-6.10.0-amd64
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.10.0-amd64*
After this operation, 412 MB disk space will be freed.
Removing linux-image-6.10.0-amd64 (6.10.12-1) ...
update-initramfs: Deleting /boot/initrd.img-6.10.0-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 6.10.0-amd64 /boot/vmlinuz-6.10.0-amd64
Generating grub configuration file ...
done

Signification : espace récupéré et config GRUB mise à jour dans les hooks de suppression du noyau.

Décision : revérifiez l’espace de /boot ; vous voulez une marge pour au moins un nouveau noyau + initramfs.

Task 11: Regenerate initramfs for the kernel you intend to boot

root@server:/# update-initramfs -u -k 6.12.0-amd64
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Signification : l’initramfs existe et a été reconstruit avec les hooks/modules actuels.

Décision : si cela échoue, corrigez avant de toucher à GRUB. Un chargeur parfait pointant vers un initramfs cassé ne démarrera toujours pas.

Task 12: Verify the root filesystem UUIDs match what the system expects

root@server:/# blkid /dev/vg0/root
/dev/vg0/root: UUID="f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c" BLOCK_SIZE="4096" TYPE="ext4"

root@server:/# grep -E '^\s*UUID=|^\s*/dev/' /etc/fstab
UUID=f3a1f9e4-7d72-4d88-8c7f-2b1b9d1a0d4c / ext4 defaults 0 1
UUID=2D3A-11F0 /boot/efi vfat umask=0077 0 1

Signification : fstab référence les UUID actuels. S’ils ne correspondent pas, le démarrage peut échouer dans initramfs ou plus tard.

Décision : si les UUID sont incorrects, corrigez /etc/fstab et tout /etc/crypttab/référence mdadm avant de régénérer l’initramfs.

Task 13: Generate a fresh GRUB config (don’t hand-edit grub.cfg)

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-amd64
Found initrd image: /boot/initrd.img-6.12.0-amd64
done

Signification : GRUB voit le noyau et l’initramfs dans /boot. S’il dit qu’il n’a trouvé aucun noyau, votre /boot n’est pas monté, ou les noyaux sont manquants, ou les scripts ne les voient pas.

Décision : ne procédez à la réinstallation de GRUB que lorsque update-grub produit une sortie cohérente.

Task 14: Reinstall GRUB for UEFI cleanly (the common Debian 13 server case)

root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Signification : le binaire EFI a été écrit sur l’ESP montée dans l’arborescence attendue. Pas d’erreur est bon ; mais vous devez toujours vérifier que les entrées firmware existent et que les fichiers sont bien présents sur l’ESP.

Décision : vérifiez les entrées NVRAM et le contenu de l’ESP ensuite.

Task 15: Check UEFI NVRAM boot entries and confirm Debian is present

root@server:/# efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* debian	HD(1,GPT,7c2f2d6a-7f0a-4d6b-8a8d-1a2d2b8c0c1e,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0001* UEFI: Built-in EFI Shell
Boot0000* UEFI PXEv4

Signification : le firmware connaît \EFI\debian\grubx64.efi et il est dans BootOrder.

Décision : si l’entrée manque ou pointe vers le mauvais GUID de disque, créez/corrigez-la, ou placez un binaire fallback dans le chemin par défaut comme sauvegarde pragmatique.

Task 16: Verify ESP file layout (because “mounted” isn’t “correct”)

root@server:/# ls -R /boot/efi/EFI
/boot/efi/EFI:
BOOT  debian

/boot/efi/EFI/BOOT:
BOOTX64.EFI

/boot/efi/EFI/debian:
grubx64.efi  grub.cfg

Signification : le fallback neutre fournisseur et l’entrée Debian existent. Sur des serveurs avec NVRAM instable, ce fichier fallback est un héros discret.

Décision : si /boot/efi/EFI est vide, vous avez installé au mauvais endroit ou l’ESP n’est pas montée. Arrêtez et corrigez cela.

Task 17: Reinstall GRUB for legacy BIOS (only if that’s your system)

root@server:/# grub-install --target=i386-pc --recheck /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Signification : le core GRUB a été écrit dans la zone de démarrage du disque. Sur GPT/BIOS, vous avez aussi besoin d’une BIOS Boot Partition ; sans elle, les installations peuvent « réussir » mais ne pas démarrer de façon fiable.

Décision : si vous êtes sur GPT et n’avez pas de BIOS Boot Partition, reconsidérez : passer à l’UEFI est souvent plus propre sur les serveurs modernes.

Task 18: Last-mile sanity check: what kernel cmdline will be used

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX_DEFAULT=//p'
"quiet"

root@server:/# cat /etc/default/grub | sed -n 's/^GRUB_CMDLINE_LINUX=//p'
""

Signification : si vous avez besoin de paramètres spéciaux (mdraid, cryptdevice, rootdelay, console=ttyS0), c’est ici que la configuration persistante vit. Ne les mettez pas dans grub.cfg.

Décision : si vous êtes uniquement à distance, définissez maintenant les paramètres de console série, régénérez la config GRUB, et évitez-vous le prochain incident aveugle.

Task 19: Exit chroot, unmount cleanly, reboot

root@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Signification : un démontage propre réduit les surprises sur les systèmes de fichiers. Le redémarrage teste toute la chaîne : firmware → GRUB → noyau → initramfs → racine.

Décision : si c’est encore en échec, capturez l’étape exacte de la nouvelle panne ; ne répétez pas la même correction en espérant une physique différente.

Blague #2 : Rebooter n’est pas une réparation. C’est un vote. Parfois il vote « toujours cassé ».

Trois mini-histoires d’entreprise (comment ça échoue en production)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils exploitaient une flotte de serveurs Debian dans un cloud privé. La plupart étaient installés en UEFI. Quelques nœuds plus anciens étaient en BIOS hérité parce que « ça n’avait pas d’importance » à l’époque, et les options de l’installateur étaient celles que le technicien avait cochées ce jour-là. Personne n’avait documenté lequel était lequel. Bien sûr que non.

Un cycle de mise à jour est passé : mise à jour du noyau plus des mises à jour GRUB. Un nœud ne revient pas. La console montrait un menu de démarrage firmware. L’ingénieur on‑call a démarré l’ISO de secours, chrooté, et a lancé grub-install /dev/sda par habitude. Ça « a marché ». Le système ne démarrait toujours pas.

Ils ont répété avec plus d’intensité : installé GRUB sur les deux disques (c’était miroir), reconstruit les configs, redémarré encore. Toujours menu firmware. Des heures se sont évaporées d’une manière que seul un boot loop sait voler du temps.

Le problème était simple et humiliant : le nœud avait été installé en mode UEFI, et le firmware cherchait une entrée EFI et un fichier ESP. Installer GRUB BIOS dans le MBR n’a rien fait à part ajouter du bruit. L’ISO de secours avait démarré en mode BIOS, ce qui a renforcé la mauvaise hypothèse.

Une fois qu’ils ont redémarré l’ISO de secours en UEFI, monté l’ESP et exécuté le grub-install ciblé UEFI, il est revenu immédiatement. L’action post-mortem était tout aussi simple : enregistrer le mode de démarrage dans l’inventaire. Pas dans la tête de quelqu’un. Pas dans une page wiki que personne n’ouvre pendant un incident. Dans les faits système que l’automatisation peut interroger.

Mini-histoire 2 : L’optimisation qui s’est retournée

Une autre entreprise avait une initiative « boot léger ». Quelqu’un a remarqué que /boot n’était utilisé que pendant le démarrage et les mises à jour, donc ils l’ont réduit agressivement. Des partitions plus petites signifiaient un imagerie plus rapide et moins d’espace perdu sur des milliers de nœuds. C’était le pitch.

Ça a marché pendant des mois. Puis une mise à jour de routine incluait un noyau et des paquets microcode. L’initramfs est devenu plus gros, comme ils ont tendance à le faire quand le support matériel s’étend et que des hooks s’accumulent. Le /boot d’un nœud s’est rempli en plein upgrade. Le paquet noyau a installé ses fichiers, mais la génération d’initramfs a échoué. La sortie du gestionnaire de paquets était là — quelque part — mais l’automatisation ne l’a pas traitée comme une erreur bloquante.

Après le reboot, GRUB affichait la nouvelle entrée noyau (parce que vmlinuz existait) et a tenté de la démarrer. L’initramfs référencé dans le menu n’existait pas. Le nœud est tombé dans un shell initramfs, a expiré, puis a redémarré, et a refait la même chose. Une parfaite petite panne auto‑entretenue.

La correction n’était pas exotique : démarrer le noyau précédent, purger correctement les anciens noyaux, reconstruire l’initramfs, régénérer la config GRUB. La leçon était que l’« optimisation » qui enlève la marge du stockage critique au démarrage est un prêt. Finalement vous remboursez avec intérêt, généralement pendant une fenêtre de maintenance que vous aviez promise comme ennuyeuse.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation plutôt financière exécutait des serveurs Debian avec des racines chiffrées (LUKS) et un contrôle strict des changements. Leurs mises à jour étaient automatisées mais volontairement étalées : mettre à jour un canari, attendre, puis déployer. Ils conservaient aussi deux noyaux connus bons installés en permanence et surveillaient l’usage de /boot.

Un soir, une mise à jour du noyau a introduit une régression pour une version spécifique du firmware du contrôleur de stockage. Le canari a redémarré et a atterri dans initramfs car la racine n’a pas été trouvée. Le service était hors ligne sur ce nœud, mais l’incident ne s’est pas propagé car le déploiement s’est automatiquement mis en pause après un contrôle de santé échoué.

Les ops ont utilisé la console pour sélectionner le noyau précédent depuis les options avancées de GRUB. Le nœud est revenu. Ils ont épinglé temporairement cette version de noyau, reconstruit l’initramfs en incluant un module spécifique, et planifié la mise à jour du firmware du contrôleur séparément.

Rien d’héroïque. Personne n’a tapé d’incantations magiques. Le système a survécu parce qu’ils ont fait les choses ennuyeuses : déploiement par paliers, conservation des noyaux de rollback, et traitement de l’espace /boot comme une ressource surveillée. Voilà à quoi ressemble la fiabilité la plupart du temps : compétence terne et reproductible.

Erreurs courantes : symptôme → cause racine → fix

Symptôme : grub-install « réussit » mais après le redémarrage vous obtenez encore le menu firmware.
Cause racine : l’ESP n’était pas montée ; vous avez installé dans /boot/efi sur le système racine, pas sur l’ESP.
Fix : montez la vraie ESP (vfat), vérifiez avec findmnt, relancez grub-install --efi-directory=/boot/efi, vérifiez avec efibootmgr -v.
Symptôme : le menu GRUB affiche le nouveau noyau, mais le démarrage tombe dans initramfs avec « cannot find UUID ».
Cause racine : l’UUID racine a changé (clonage/remplacement de disque) ou le nom des mappings crypt/mdraid a changé ; l’initramfs a encore de vieilles références.
Fix : corrigez /etc/fstab, /etc/crypttab, et la config mdadm si applicable ; lancez update-initramfs -u -k all.
Symptôme : update-grub ne trouve aucun noyau.
Cause racine : /boot non monté (partition séparée), ou noyaux supprimés/jamais installés à cause d’erreurs dpkg.
Fix : montez /boot ; vérifiez /boot/vmlinuz-* ; réparez les paquets avec dpkg --configure -a et apt-get -f install.
Symptôme : boucle de démarrage après sélection GRUB ; kernel panic tôt.
Cause racine : initramfs cassé, pilote de stockage manquant, ou régression dans le nouveau noyau.
Fix : démarrez un noyau antérieur ; reconstruisez l’initramfs ; envisagez d’épingler le paquet noyau jusqu’à résolution de la régression.
Symptôme : invite grub rescue>, ls montre des partitions mais normal ne peut pas charger.
Cause racine : le prefix de GRUB pointe vers la mauvaise partition ou /boot/grub est manquant/corrompu.
Fix : utilisez un rescue/live, montez correctement, chrootez, réinstallez GRUB et régénérez la config ; vérifiez aussi l’intégrité disque/FS.
Symptôme : systèmes avec Secure Boot activé refusent de démarrer après une mise à jour GRUB.
Cause racine : binaires EFI non signés ou chaîne shim non conforme ; ou mauvais ensemble de paquets installé.
Fix : assurez-vous d’installer les paquets signés corrects pour votre politique ; désactivez temporairement Secure Boot uniquement comme étape diagnostique, puis restaurez une chaîne de démarrage conforme.
Symptôme : systèmes root sur mdraid tombent dans initramfs sans assemblage d’arrays.
Cause racine : initramfs manque la config mdadm ou les modules ; ou mismatch metadata/UUID après remplacement de disque.
Fix : confirmez les arrays avec mdadm --examine en rescue ; corrigez /etc/mdadm/mdadm.conf ; reconstruisez initramfs.

Checklists / plan étape par étape

Checklist A: If you can see a GRUB menu

Sélectionnez Advanced options et démarrez le noyau précédent.
Une fois démarré, vérifiez l’espace de /boot et l’état des paquets.
Reconstruisez l’initramfs pour le noyau le plus récent une fois l’espace suffisant.
Exécutez update-grub, puis redémarrez et testez le noyau le plus récent.
Si le firmware ne trouve toujours pas GRUB de façon cohérente, réinstallez GRUB (UEFI/BIOS correctement) et vérifiez avec efibootmgr.

Checklist B: If you’re stuck in firmware menu or grub rescue

Démarrez un environnement de secours dans le bon mode (UEFI vs BIOS).
Identifiez les disques/partitions avec lsblk. Localisez la racine, /boot, et l’ESP.
Déverrouillez LUKS / assemblez RAID / importez les pools selon les besoins avant le montage.
Montez la racine sur /mnt, puis montez /mnt/boot et /mnt/boot/efi si présents.
Bind-montez /dev, /proc, /sys, puis chrootez.
Réparez l’état dpkg : dpkg --audit, apt-get -f install.
Corrigez l’espace /boot si nécessaire ; supprimez proprement les anciens noyaux.
Reconstruisez l’initramfs pour le noyau cible.
Exécutez update-grub et confirmez qu’il trouve noyaux/initrd.
Réinstallez GRUB sur la cible correcte (UEFI ou BIOS).
Vérifiez avec efibootmgr -v et la liste des fichiers de l’ESP.
Redémarrez et surveillez la console jusqu’au premier démarrage réussi.

Checklist C: Guardrails to prevent the next one

Surveillez l’usage de /boot et alertez à 70–80 %.
Conservez au moins un noyau antérieur connu bon installé.
Déployez par paliers avec canaris ; mettez en pause le rollout sur échec de démarrage.
Assurez-vous que l’ESP est montée et vérifiée pendant les mises à jour (et dans la gestion de configuration).
Standardisez le mode de démarrage au sein du parc ; enregistrez‑le dans l’inventaire.
Pour les systèmes accessibles uniquement à distance, configurez de façon persistante les paramètres de console série du noyau.

FAQ

1) Is this really a “GRUB problem” if I drop into initramfs?

Généralement non. Si le noyau a démarré et que vous êtes dans initramfs, GRUB a fait sa part. Concentrez-vous sur la découverte du périphérique racine : UUIDs, déverrouillage LUKS, assemblage mdraid, pilotes manquants, ou régression du noyau. Reconstruisez l’initramfs et validez /etc/fstab//etc/crypttab.

2) Why does `grub-install` succeed but nothing changes?

Le plus courant : l’ESP n’était pas montée. Vous avez écrit des fichiers EFI dans un répertoire sur votre système racine, pas sur la partition FAT lisible par le firmware. Vérifiez toujours avec findmnt /boot/efi et contrôlez le contenu de l’ESP ensuite.

3) Should I copy `grubx64.efi` to the fallback path?

Sur des serveurs avec des entrées NVRAM peu fiables, avoir \EFI\BOOT\BOOTX64.EFI peut vous sauver. Mais faites‑le délibérément : assurez-vous que c’est sur l’ESP, et gardez‑le cohérent avec votre chaîne de chargeur voulue. Ne laissez pas trois chargeurs conflictuels et appelez ça de la résilience.

4) Can I just delete old files from `/boot` to free space?

Vous pouvez, et parfois ça marche, mais cela laisse aussi dpkg croire que les paquets existent toujours. Supprimez les noyaux via apt-get remove --purge linux-image-X pour que les hooks mettent à jour initramfs et la config GRUB correctement.

5) My system uses RAID1 for the ESP. Is that okay?

UEFI attend de la FAT sur une ESP ; les stratégies de mirroring varient. Certains sites gardent des ESP identiques sur les deux disques et les mettent à jour toutes les deux. Ça peut fonctionner, mais il faut l’opérationnaliser (processus de mise à jour, vérification). Si vous ne mettez à jour qu’une ESP, vous créez un basculement vers une réalité plus ancienne.

6) What if `efibootmgr` isn’t available in the chroot?

Installez‑le dans le chroot (apt-get install efibootmgr) si le réseau/les sources de paquets sont disponibles. Sinon, vous pouvez toujours vous assurer que l’ESP contient les bons fichiers ; beaucoup de firmwares démarrent le chemin fallback même sans entrée NVRAM.

7) Does Secure Boot change the rollback steps?

La mécanique est la même — monter l’ESP, réinstaller les paquets corrects, régénérer les configs — mais les binaires autorisés diffèrent. Si Secure Boot est appliqué, les binaires EFI non signés peuvent être refusés. Traitez « désactiver Secure Boot » comme une étape diagnostique, pas comme une solution permanente, sauf si la politique le permet.

8) How do I know which disk to run `grub-install` on in BIOS mode?

Choisissez le disque que le BIOS boote en premier (souvent le premier dans l’ordre de démarrage), et sur des systèmes en miroir envisagez d’installer intentionnellement sur les deux disques. Mais ne faites pas du spray-and-pray ; confirmez avec l’ordre de démarrage du firmware et votre topologie RAID. En mode BIOS, vous installez sur le périphérique disque entier, pas sur une partition.

9) Why did this happen right after a firmware update?

Les mises à jour firmware peuvent réinitialiser les entrées NVRAM ou changer l’ordre de démarrage. Votre OS et l’ESP peuvent être corrects ; le firmware a simplement oublié l’entrée Debian. Vérifiez avec efibootmgr -v et restaurez l’entrée de démarrage ou le chemin fallback.

10) What’s the single best prevention for “won’t boot after updates”?

Gardez des options de rollback : au moins un noyau antérieur installé, suffisamment d’espace /boot, déploiements par paliers, et vérifications automatisées que l’ESP est montée pendant les mises à jour du chargeur. La fiabilité n’est pas un acte héroïque ; c’est de l’intérêt composé.

Conclusion : étapes suivantes pour réduire les incidents répétés

Quand Debian 13 ne démarre plus après des mises à jour, traitez‑le comme un problème de chaîne. Le firmware doit trouver un chargeur, le chargeur doit trouver modules/config, GRUB doit pointer vers un noyau et un initramfs qui existent, et l’initramfs doit pouvoir déverrouiller/assembler/monter la racine. Réparez le maillon brisé, pas toute la chaîne avec un marteau.

Faites cela ensuite, pendant que l’incident est frais :

Standardisez le mode de démarrage dans votre parc (UEFI fortement recommandé sur le matériel moderne) et enregistrez‑le dans l’inventaire.
Ajoutez de la surveillance pour l’utilisation de /boot et alertez avant que cela ne devienne une erreur de packaging.
Conservez au moins un noyau connu bon installé ; ne « nettoyez » pas votre chemin de rollback.
Automatisez un contrôle post‑mise à jour : ESP montée, update-initramfs réussi, update-grub a trouvé les noyaux, et efibootmgr montre une entrée cohérente.
Si vous utilisez racine chiffrée, RAID, ou ZFS : validez que votre initramfs inclut les hooks/modules appropriés après chaque changement majeur. L’early userspace fait partie de votre pile de stockage.