Debian 13 : entrée UEFI disparue — restaurer le démarrage avec efibootmgr en quelques minutes

Ce qui a réellement cassé quand l’entrée UEFI a disparu

Le démarrage UEFI repose sur un tabouret à trois pieds :

1. Entrées NVRAM du firmware (variables Boot####) qui pointent vers un exécutable EFI sur un disque.
2. La partition système EFI (ESP), une partition FAT32 qui contient les binaires .efi et les configurations.
3. Une chaîne de chargeur de démarrage (souvent shimx64.efi → grubx64.efi → votre noyau).

Quand vous perdez une entrée de démarrage, vous avez généralement perdu seulement la jambe n°1. Les fichiers sur le disque existent toujours. Le firmware a juste « oublié » où se trouve Debian, ou a décidé de s’en désintéresser.

Pourquoi cela arrive-t-il ? Les causes courantes incluent :

• Réinitialisations du firmware après une coupure de courant, des problèmes de batterie, ou une mise à jour du BIOS/UEFI.
• La NVRAM est pleine ou corrompue (oui, ça existe).
• Un autre installateur d’OS réécrit « utilement » BootOrder.
• Certaines plateformes suppriment silencieusement des entrées qui pointent vers des disques temporairement absents (USB/NVMe hot swap, drama du contrôleur RAID).
• Des bascules de Secure Boot changeant le chemin préféré (shim vs GRUB direct) et rendant votre entrée « incorrecte » pour le firmware.

La bonne nouvelle : c’est réparable rapidement et en toute sécurité. La mauvaise nouvelle : il faut être précis, car UEFI vous permettra de créer une entrée parfaite pointant vers le mauvais disque, ce qui revient à ne rien faire mais avec plus de confiance.

Faits intéressants et un peu d’histoire (parce que ça compte)

• UEFI a remplacé le BIOS non seulement pour des menus plus jolis, mais pour standardiser le démarrage au-delà des limites 2 TB/MBR et fournir un environnement pré-boot programmable.
• La partition système EFI est FAT intentionnellement : les fabricants de firmware avaient besoin d’un format lisible universellement sans fournir toute une ménagerie de systèmes de fichiers.
• Les entrées de démarrage UEFI vivent dans la NVRAM, généralement sauvegardée sur une mémoire SPI de la carte mère, pas sur votre disque. C’est pourquoi réinstaller GRUB ne répare pas toujours une entrée manquante.
• Il existe un chemin « fallback » standardisé : \EFI\BOOT\BOOTX64.EFI sur x86_64. Si le firmware ne trouve pas d’entrées, il peut essayer celui-ci. Certains fabricants comptent dessus plus qu’ils ne l’admettent.
• Secure Boot ne « sécurise pas Linux » ; il sécurise quels binaires peuvent s’exécuter en pré-boot. Le système peut toujours être mal configuré ou compromis après le démarrage. C’est un outil de chaîne de confiance, pas une baguette magique.
• efibootmgr parle à la NVRAM via efivarfs (généralement monté sur /sys/firmware/efi/efivars). Si vous avez démarré en mode legacy, il ne peut pas gérer les variables UEFI, parce qu’elles ne sont pas disponibles.
• Certain firmware imposent de petites quotas NVRAM, et les fournisseurs stockent parfois des logs de crash ou diagnostics dans le même pool. Vos entrées de démarrage peuvent perdre un combat de coq contre une « télémétrie utile ».
• L’exécutable UEFI de GRUB n’est pas la configuration. La configuration se trouve typiquement dans /boot/grub/grub.cfg sur votre système Linux, tandis que le binaire EFI sur l’ESP n’est qu’un stub chargeur.
• La chaîne signée de Debian utilise couramment shimx64.efi pour satisfaire Secure Boot tout en permettant à GRUB de se charger, avec des clés de signature contrôlées par Debian plutôt que de vous forcer à construire votre propre chaîne.

Playbook de diagnostic rapide : trouver le goulot en 5 minutes

Première étape : êtes-vous vraiment démarré en mode UEFI ?

Si vous êtes dans un environnement de secours (ISO live, PXE rescue, assistance distante avec un crash cart), confirmez si le noyau voit les variables UEFI. Sinon, arrêtez et redémarrez le média de secours en mode UEFI. Rien d’autre ne restera en place.

Deuxième étape : avez-vous une ESP et contient-elle les chargeurs Debian ?

Trouvez l’ESP, montez-la et cherchez \EFI\debian\. Si les fichiers manquent, le problème est sur le disque : réinstallez grub-efi-amd64 (et possiblement shim-signed) et régénérez.

Troisième étape : la NVRAM est-elle inscriptible et pas pleine ?

Si efibootmgr échoue à créer des entrées, votre firmware peut bloquer les écritures, le système de fichiers des variables peut ne pas être monté, Secure Boot peut restreindre les mises à jour de variables (moins fréquent), ou la NVRAM peut être pleine/corrompue. Dans ce cas, changez de tactique : utilisez le chemin de secours EFI/BOOT/BOOTX64.EFI, ou nettoyez les entrées NVRAM si vous le pouvez.

Quatrième étape : validez BootOrder et le chemin réel du périphérique

Même quand vous créez une entrée, elle peut pointer vers le mauvais disque/partition si vous avez deviné. Confirmez les numéros de disque et de partition. Puis définissez BootOrder volontairement. « Laisser le firmware trier » est la façon dont vous finissez par regarder un serveur démarrer Windows à nouveau.

Tâches pratiques : commandes, sorties, décisions (le playbook qui marche)

Voici les tâches que j’exécute réellement. Chacune a trois parties : la commande, ce que signifie la sortie, et la décision à prendre. Exécutez-les depuis un shell de secours Debian si le système ne démarre pas. Vous pouvez aussi les faire depuis un système installé, mais le scénario d’entrée manquante implique généralement que vous ne pouvez pas démarrer.

Task 1: Confirm UEFI mode is available

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

Signification : Si le répertoire existe, vous avez démarré en mode UEFI. S’il manque, vous êtes en mode legacy/CSM.

Décision : Si absent, redémarrez le média de secours et choisissez l’option de démarrage UEFI dans le menu du firmware. N’utilisez pas efibootmgr tant que ceci n’est pas présent.

Task 2: Confirm efivarfs is mounted (NVRAM access)

cr0x@server:~$ mount | grep -E 'efivars|efi'
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Signification : efivarfs est l’interface noyau vers les variables UEFI.

Décision : Si non monté, montez-le (Task 3) ou corrigez pourquoi votre noyau de secours ne le supporte pas.

Task 3: Mount efivarfs if needed

cr0x@server:~$ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
cr0x@server:~$ mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Signification : Sans cela, efibootmgr peut afficher « EFI variables are not supported » ou échouer à écrire.

Décision : Si le montage échoue, vous êtes peut-être en mode legacy ou utilisez un noyau sans support des variables EFI.

Task 4: Inspect current BootOrder and entries

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0001,0002
Boot0001* UEFI: Built-in EFI Shell	HD(1,GPT,8f2c0f9f-6c7f-4f84-9b8c-9f5f3b2f0b0a,0x800,0x32000)/File(\EFI\tools\Shell.efi)
Boot0002* UEFI PXEv4 (MAC:001122334455)	PciRoot(0x0)/Pci(0x1,0x1)/MAC(001122334455,0)
Boot0007* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Signification : Vous pouvez voir si une entrée « debian » existe, et quel chemin fichier elle cible.

Décision : Si l’entrée Debian manque, vous la recréerez. Si elle existe mais pointe vers un fichier inexistant, réparez le contenu de l’ESP ou corrigez le chemin.

Task 5: Find the EFI System Partition

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTLABEL     MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2     2G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 boot
└─nvme0n1p3 951.4G crypto_LUKS 0fc63daf-8483-4772-8e79-3d69d8477de4 root

Signification : L’ESP est typiquement vfat avec le type GPT c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

Décision : Notez le périphérique (ici /dev/nvme0n1p1). Si vous ne voyez pas d’ESP, vous pourriez être en boot legacy, le partitionnement peut être incorrect, ou vous êtes sur du matériel vendeur étrange.

Task 6: Mount the ESP and inspect contents

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo find /mnt/esp/EFI -maxdepth 2 -type f -name '*.efi' | sort
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/debian/grubx64.efi
/mnt/esp/EFI/debian/shimx64.efi

Signification : Si vous voyez les binaires EFI de Debian, le côté disque est sain et l’entrée NVRAM est probablement le problème.

Décision : Si /mnt/esp/EFI/debian/ est manquant ou vide, il faut réinstaller GRUB/shim sur l’ESP.

Task 7: Verify the loader file the firmware entry points to

cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/shimx64.efi && echo "shim present"
shim present
cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/grubx64.efi && echo "grub present"
grub present

Signification : Confirme que le fichier exact existe. Cela évite le classique « l’entrée pointe vers grubx64.efi mais seul shim existe ».

Décision : Si absent, réinstallez les paquets et relancez grub-install (Task 10–11).

Task 8: Check if the ESP filesystem is unhappy

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -n /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
...
/dev/nvme0n1p1: 12 files, 1024/130560 clusters

Signification : L’exécution en -n est en lecture seule. Vous vérifiez une corruption évidente sans rien modifier.

Décision : S’il signale des erreurs, planifiez une réparation correcte (retirez -n) et attendez-vous à réinstaller les fichiers de démarrage s’ils ont été endommagés.

Task 9: Check kernel logs for EFI variable write failures

cr0x@server:~$ dmesg | grep -i -E 'efivars|efi:|secure|nvram' | tail -n 20
[    0.214321] efi: EFI v2.80 by American Megatrends
[    0.214322] efi: ESRT=0xb7f3c000 ACPI=0x9b5f4000 ACPI 2.0=0x9b5f4000 SMBIOS=0xb7f2e000
[    1.902114] efivars: Registered efivars operations

Signification : Vous voulez voir une initialisation EFI normale. Si vous voyez « efivars: write error » ou « no space left on device », c’est votre coupable.

Décision : S’il y a des erreurs d’écriture, prévoyez d’utiliser le chemin de secours ou de nettoyer les entrées NVRAM (Task 14–15).

Task 10: Prepare a chroot (when repairing from rescue)

cr0x@server:~$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:
cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ sudo mount /dev/vg0/root /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

Signification : Le root du système installé, /boot et l’ESP sont montés aux emplacements standards pour Debian.

Décision : Si /boot/efi n’est pas monté dans le chroot, grub-install peut écrire au mauvais endroit et vous « réparerez » rien.

Task 11: Bind-mount system directories and chroot

cr0x@server:~$ for d in /dev /dev/pts /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | grep -E '/boot/efi|efivars'
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/sys/firmware/efi/efivars on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Signification : Le chroot voit la vraie ESP et efivars. Bien. Vous opérez sur l’état réel du système.

Décision : Si efivars n’est pas visible dans le chroot, bind-montez correctement /sys et confirmez que vous avez démarré le rescue en mode UEFI.

Task 12: Reinstall Debian’s UEFI boot packages (signed chain)

cr0x@server:/# apt-get update
Hit:1 cdrom://Debian GNU/Linux 13.0.0 _Trixie_ - Official amd64 NETINST 20251201-10:22  trixie InRelease
Reading package lists... Done
cr0x@server:/# apt-get install --reinstall grub-efi-amd64 shim-signed
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Setting up shim-signed (1.60+15.8-1) ...
Setting up grub-efi-amd64 (2.12-2) ...

Signification : Vous restaurez des binaires EFI et scripts connus comme bons. Les paquetages Debian déclenchent généralement aussi les étapes postinst appropriées.

Décision : Si Secure Boot est désactivé et que vous ne voulez pas de shim, vous pouvez l’omettre. Mais dans des flottes mixtes, réinstaller shim évite des surprises ultérieures.

Blague n°1 : la NVRAM UEFI est comme un petit placard — tout rentre jusqu’à ce que vous ayez besoin d’un manteau de plus, et là rien ne rentre et tout le monde blâme le manteau.

Task 13: Run grub-install explicitly (when packages weren’t enough)

cr0x@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 : Cela écrit le chargeur dans l’ESP sous /boot/efi/EFI/debian/, et peut aussi créer une entrée NVRAM.

Décision : Si l’erreur indique « cannot find EFI directory », votre ESP n’est pas monté là où vous le pensez. Arrêtez et corrigez les montages.

Task 14: Regenerate GRUB config (sanity, not superstition)

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

Signification : Cela valide que votre système installé voit des noyaux et peut générer un menu cohérent.

Décision : S’il ne trouve pas de noyaux, vous résolvez le mauvais problème : il se peut que /boot soit mal monté ou que des paquets noyau manquent.

Task 15: Create (or recreate) the UEFI boot entry with efibootmgr

cr0x@server:/# efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
BootCurrent: 0007
BootOrder: 0007,0001,0002
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Signification : Cela écrit une nouvelle variable Boot#### pointant vers le chargeur. Notez que le disque (-d) et le numéro de partition (-p) font tout le travail.

Décision : Si cela réussit, mettez BootOrder pour la préférer (Task 16). Si l’erreur est « No space left on device », passez au nettoyage de la NVRAM ou au boot de secours (sections ultérieures).

Task 16: Put Debian first in BootOrder (be bossy)

cr0x@server:/# efibootmgr
BootCurrent: 0007
BootOrder: 0007,0001,0002,0008
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)
cr0x@server:/# efibootmgr -o 0008,0007,0001,0002
BootOrder: 0008,0007,0001,0002

Signification : Vous ordonnez explicitement les cibles de démarrage. Sinon le firmware peut continuer à démarrer PXE ou un shell en premier.

Décision : Définissez toujours BootOrder explicitement sur les serveurs. Des menus conviviaux ne sont pas une stratégie de fiabilité.

Task 17: One-time boot into the new entry (safe test)

cr0x@server:/# efibootmgr -n 0008
BootNext: 0008

Signification : BootNext définit un démarrage unique. C’est une manière à faible risque de tester sans réarranger définitivement tout.

Décision : Utilisez BootNext quand vous êtes en intervention distante et voulez que le système revienne à un défaut connu si votre changement échoue.

Task 18: Verify the fallback loader exists (insurance)

cr0x@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 09:26 /boot/efi/EFI/BOOT/BOOTX64.EFI

Signification : Certaines plateformes démarreront automatiquement ceci lorsque les entrées NVRAM manquent. D’autres non. Mais l’avoir reste utile quand vous improvisez.

Décision : Si manquant, envisagez de le créer (section fallback) après avoir restauré l’entrée principale.

Task 19: Exit chroot cleanly and reboot

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

Signification : Vous videz les écritures et retirez les montages pour éviter un état sale. Particulièrement important si vous avez exécuté des vérifications de système de fichiers ou touché l’ESP.

Décision : Si le redémarrage retombe dans le firmware, ne paniquez pas — revenez à la Task 4 et confirmez que l’entrée existe toujours. Si elle a de nouveau disparu, vous avez probablement un problème de firmware/NVRAM ou une protection en écriture.

Recréer l’entrée UEFI Debian avec efibootmgr (la réparation chirurgicale)

La commande la plus importante est :

• -c créer une nouvelle entrée
• -d le périphérique disque (pas une partition)
• -p le numéro de partition de l’ESP sur ce disque
• -L étiquette affichée dans les menus du firmware
• -l chemin du chargeur à l’intérieur de l’ESP, en utilisant des barres obliques inverses et un chemin absolu depuis la racine de l’ESP

Deux modèles que j’utilise :

Pattern A: Secure Boot compatible (shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
Boot0009* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Utiliser quand : Secure Boot est activé, ou vous ne contrôlez pas la politique de la flotte et voulez une entrée qui fonctionne dans tous les cas.

Pattern B: Direct GRUB (no shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian (grub)" -l '\EFI\debian\grubx64.efi'
Boot0010* debian (grub)	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\grubx64.efi)

Utiliser quand : Secure Boot est désactivé et vous voulez la chaîne la plus simple. Utile aussi pour déboguer des échecs liés à shim.

Quand efibootmgr « fonctionne » mais le démarrage échoue

Les entrées UEFI peuvent être trompeusement correctes. Le firmware stocke un device path qui inclut un GUID de partition GPT. Si vous avez cloné des disques, restauré des images ou changé du matériel, le GUID peut changer. Parfois les entrées continuent de pointer vers l’ancien GUID et deviennent mortes.

En pratique : si votre entrée montre un chemin HD() avec un GUID qui ne correspond pas au PARTUUID actuel de l’ESP, recréez-la avec efibootmgr plutôt que d’essayer de l’éditer.

Une citation à garder au mur (idée paraphrasée)

Idée paraphrasée : Gene Kranz soulignait que face à une panne on reste calme, on travaille le problème, et on évite les improvisations guidées par la panique.

Utiliser le chemin de secours : BOOTX64.EFI (quand la NVRAM est hostile)

Parfois la NVRAM ne conserve pas les entrées. Vous en créez une, redémarrez, et elle disparaît comme un commit coupable. Ou efibootmgr renvoie « No space left on device ». Ou la plateforme bloque les écritures de variables sauf avec des outils du fournisseur.

C’est là que le chemin de secours UEFI justifie son existence : \EFI\BOOT\BOOTX64.EFI pour x86_64. Beaucoup de firmwares le démarreront quand les entrées manquent, ou vous pouvez sélectionner manuellement l’option « UEFI: device » du disque et il prendra le fallback.

Rendre Debian démarrable via le fallback

Si vous avez déjà le shim de Debian sur l’ESP, copiez-le dans l’emplacement de secours. Préférez shim si Secure Boot peut être activé.

cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo mkdir -p /mnt/esp/EFI/BOOT
cr0x@server:~$ sudo cp -a /mnt/esp/EFI/debian/shimx64.efi /mnt/esp/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo sync
cr0x@server:~$ sudo ls -l /mnt/esp/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 10:11 /mnt/esp/EFI/BOOT/BOOTX64.EFI

Signification : Vous avez maintenant un chargeur de secours bootable même si la NVRAM est effacée.

Décision : Utilisez ceci si vous suspectez que le firmware supprime des entrées, si la NVRAM est pleine, ou si vous êtes sur un site distant et voulez le filet de sécurité le plus simple qui « boote même s’il oublie ».

Quid de la configuration quand on utilise le fallback ?

Shim/GRUB doit toujours trouver la config GRUB et le système de fichiers Linux. Le GRUB de Debian contient typiquement une logique pour trouver /boot/grub. Si vous avez des layouts exotiques (mdadm, LUKS, multiples ESP), testez. Ne supposez pas.

Blague n°2 : le chemin de secours UEFI est comme laisser une clé sous le paillasson — sauf que le paillasson est standardisé par un comité.

Réalité de Secure Boot : shim, GRUB signé et éviter l’auto-infligé

Secure Boot change les modes de défaillance. Avec Secure Boot activé :

• Le firmware n’exécutera que des binaires EFI signés par des clés de confiance.
• Debian utilise typiquement shimx64.efi signé d’une manière acceptée par le firmware (via des ancres de confiance communes), puis shim valide GRUB.
• Si vous pointez une entrée directement vers un grubx64.efi non signé, vous pouvez obtenir un échec immédiat qui ressemble à « il n’a pas démarré » sans journaux.

Conseils pratiques :

• Si vous ne connaissez pas l’état de Secure Boot, supposez qu’il est activé. Créez l’entrée pointant vers shim. C’est la valeur par défaut la moins à risque.
• N’activez/désactivez pas Secure Boot comme « solution ». Ce n’est pas une réparation ; c’est un changement de politique. Cela peut aussi casser d’autres hôtes si vous le traitez comme une option de redémarrage occasionnelle.
• Gardez l’ESP lisible et sans fantaisie. Certains tentent d’« optimiser » en compressant ou dédupliquant le contenu de l’ESP (avec des outils étranges). Ne le faites pas. C’est du FAT32. Laissez-le rester FAT32.

Trois mini-histoires en entreprise des tranchées du démarrage

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

L’équipe avait une petite flotte de serveurs Debian qui démarraient depuis des NVMe en miroir. Une mise à jour de firmware de la carte mère était planifiée pendant une fenêtre de maintenance. Tout semblait routinier : patch, reboot, vérification des services, rentrer chez soi.

Après la mise à jour, un sous-ensemble de nœuds est revenu dans le shell UEFI. L’astreignant a supposé que le chargeur avait été corrompu par la mise à jour. Ils ont réinstallé GRUB depuis le mode rescue, deux fois, parce que la première réinstallation « n’avait pas pu échouer ». Ça ne démarrait toujours pas. Les esprits se sont échauffés. Le prompt du shell restait poli et impassible.

Le vrai problème : la mise à jour du firmware a réinitialisé la NVRAM et aussi changé la préférence de mode de démarrage. Les serveurs préféraient maintenant PXE et les entrées shell, et l’entrée Debian n’était plus présente. Réinstaller GRUB a correctement écrit les fichiers sur l’ESP, mais personne n’a recréé l’entrée NVRAM ni corrigé BootOrder.

Une fois que quelqu’un a exécuté efibootmgr -v et a vraiment regardé, la solution a été triviale : créer l’entrée pointant vers shim et définir BootOrder. La leçon n’était pas « les mises à jour de firmware sont mauvaises ». La leçon était : ne supposez pas « corruption du chargeur » quand le système n’essaie même pas de charger votre chargeur.

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

Une autre organisation voulait des « partitions de démarrage plus propres ». Ils ont standardisé les images et réduit l’ESP au minimum : un chargeur, un répertoire vendor, pas d’extras. Ils ont aussi purgé agressivement les entrées UEFI « inutilisées » dans le cadre de la provision, car certaines machines arrivaient avec une ménagerie de diagnostics d’usine.

Puis ils ont ajouté des postes de développeurs en dual-boot dans le même framework d’automatisation. Un script, réutilisé partout, supprimait tout ce qui n’était pas exactement étiqueté « debian » et réordonnait BootOrder. Sur le papier, propre. En réalité, les postes avaient Windows utilisant BitLocker et nécessitaient que son entrée de démarrage reste stable.

La mise à jour Windows suivante a réécrit sa propre entrée et BootOrder (comme il a tendance à le faire). L’automatisation a ensuite supprimé cette entrée, et réarrangé les choses. Le recovery Windows s’est déclenché, les utilisateurs ont contacté le helpdesk, et l’équipe plateforme a reçu une semaine de rappel que « standardiser » n’est pas la même chose que « supprimer ce que vous ne comprenez pas ».

Ils ont corrigé cela en rendant le script conscient des rôles de plateforme, en laissant les entrées non-Linux intactes sauf si explicitement demandé, et en s’appuyant davantage sur le chemin de secours comme soupape de sécurité plutôt que d’imposer un BootOrder unique parfait partout.

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

Une banque (oui, vraiment) avait une politique : chaque serveur Linux démarrant en UEFI doit avoir à la fois une entrée NVRAM correcte et un chargeur de secours maintenu à \EFI\BOOT\BOOTX64.EFI. Ils exigeaient aussi que l’ESP fasse partie des procédures de sauvegarde/restauration, même si c’est petit et qu’on a l’impression que ce n’est « pas réel ».

Un site a connu des problèmes d’alimentation répétés. Plusieurs systèmes sont revenus avec des entrées NVRAM effacées. Normalement cela devient un désastre progressif : interventions locales, sessions console, bidouillages manuels. À la place, les hôtes ont démarré via le fallback, shim a chargé GRUB, et le système d’exploitation est arrivé. Les applications n’ont même pas remarqué. Le ticket d’incident a été presque anticlimactique.

Plus tard, l’équipe a recréé les entrées NVRAM durant la journée et a trouvé la cause racine (firmware plus alimentation instable). Mais le résultat immédiat pour le business a été ennuyeux : les services sont restés opérationnels. L’ennui est l’objectif.

C’est pour cela qu’on effectue le travail peu sexy : chemins de démarrage redondants, commandes de récupération documentées, et une checklist qui ne dépend pas des héroïques.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: efibootmgr says “EFI variables are not supported”

Cause racine : Vous avez démarré l’environnement de secours en mode legacy/CSM, ou efivarfs n’est pas disponible.

Correction : Redémarrez le média de secours en mode UEFI (Task 1). Assurez-vous que efivarfs est monté (Task 2–3).

2) Symptom: Debian entry exists, but it still boots to firmware setup

Cause racine : BootOrder ne l’inclut pas, ou elle se trouve après PXE/shell, ou le firmware la saute à cause d’une tentative échouée.

Correction : Définissez BootOrder explicitement (Task 16). Utilisez BootNext pour tester (Task 17).

3) Symptom: Debian entry points to grubx64.efi, but Secure Boot is enabled and it won’t start

Cause racine : Le firmware refuse d’exécuter un chargeur non signé.

Correction : Pointez l’entrée vers \EFI\debian\shimx64.efi à la place (Task 15, Pattern A). Réinstallez shim-signed si nécessaire (Task 12).

4) Symptom: efibootmgr create fails with “No space left on device”

Cause racine : Le stockage des variables NVRAM est plein.

Correction : Supprimez des entrées obsolètes (efibootmgr -b #### -B) et réessayez, ou utilisez le chemin de secours (section fallback) si les écritures restent peu fiables.

5) Symptom: efibootmgr works, but entry disappears after reboot

Cause racine : Bug du firmware, protection en écriture, ou réinitialisation des paramètres (parfois due à une pile CMOS défaillante ou des politiques « restore defaults » agressives).

Correction : Utilisez le chemin de secours BOOTX64.EFI pour plus de résilience, et planifiez une remediation matérielle/firmware. Si possible, mettez à jour le firmware à nouveau ou désactivez les fonctionnalités « OS optimized defaults » qui suppriment les entrées.

6) Symptom: GRUB starts, but kernel not found / drops to rescue

Cause racine : Ce n’est pas une entrée UEFI manquante. C’est un problème de configuration de démarrage Linux ou de stockage : mauvais UUID de root, /boot manquant, mauvaise assemblage LUKS/mdadm.

Correction : Validez les montages dans le chroot (Task 10–11), exécutez update-grub (Task 14), confirmez que initramfs contient les modules nécessaires, et vérifiez /etc/fstab et crypttab.

7) Symptom: Entry points to the right file, file exists, but it still won’t boot

Cause racine : L’ESP est sur un disque que le firmware ne peut plus lire (changement de mode du contrôleur, remappage RAID, changements de namespace NVMe), ou l’entrée référence un GUID de partition obsolète après clonage.

Correction : Recréez l’entrée avec le disque et la partition corrects (Task 15). Si le mode du contrôleur a changé (AHCI/RAID), revenez en arrière ou assurez-vous que le firmware peut accéder à l’ESP dans ce mode.

Checklists / plan étape par étape (ennuyeux, rapide, répétable)

Checklist A: You have console access and a rescue ISO

1. Démarrez l’ISO de secours en mode UEFI (vérifiez avec Task 1).
2. Montegez efivarfs si nécessaire (Task 2–3).
3. Inspectez les entrées NVRAM (Task 4). Décidez si l’entrée Debian manque ou est incorrecte.
4. Trouvez et montez l’ESP (Task 5–6). Confirmez que les fichiers de chargeur existent (Task 7).
5. Si les fichiers de chargeur manquent, chrootez et réinstallez (Task 10–14).
6. Créez ou recréez l’entrée de démarrage (Task 15).
7. Définissez BootOrder (Task 16). Optionnellement définissez BootNext pour un test (Task 17).
8. Redémarrez et observez.

Checklist B: NVRAM is full or firmware keeps forgetting

1. Confirmez que l’ESP contient shim/grub de Debian (Task 6–7).
2. Créez un chargeur de secours à \EFI\BOOT\BOOTX64.EFI (section fallback).
3. Tentez de nettoyer la NVRAM uniquement si vous pouvez le faire en toute sécurité (supprimez des PXE shells ou anciennes entrées d’OS clairement obsolètes).
4. Planifiez une remediation du firmware : mise à jour, réinitialisation prudente, remplacement de la pile CMOS si pertinent, et documentez le comportement.

Checklist C: Dual-boot or multiple Linux installs

1. Ne supprimez pas d’entrées de façon aveugle. Dressez d’abord la liste (Task 4) et cartographiez chacune vers un chemin ESP.
2. Utilisez des étiquettes explicites : debian-prod, debian-rescue, windows.
3. Préférez des entrées basées sur shim si Secure Boot peut être utilisé par n’importe quel OS.
4. Gardez un chargeur de secours qui démarre votre OS principal, pas un installateur.

FAQ

1) Why would a UEFI boot entry disappear at all?

Parce qu’elle est stockée dans la NVRAM de la carte mère, pas sur le disque. Les mises à jour du firmware, réinitialisations, événements d’alimentation ou problèmes de quota NVRAM peuvent effacer ou élaguer les entrées.

2) If the ESP is intact, why doesn’t the machine just find it?

UEFI ne « scanne et devine » généralement pas comme l’ancien BIOS. Il suit les entrées BootOrder. Certains firmwares essaieront les chemins de secours, mais vous ne pouvez pas compter dessus sauf si vous l’avez configuré.

3) Do I need efibootmgr or can I just reinstall GRUB?

Réinstaller GRUB répare les fichiers de chargeur sur le disque. efibootmgr répare les pointeurs NVRAM. Quand l’entrée a disparu, vous avez généralement besoin d’efibootmgr (ou d’un boot de secours) pour réintroduire le pointeur.

4) What’s the right loader path format in efibootmgr?

Utilisez un chemin absolu à barres inverses à l’intérieur de l’ESP, comme \EFI\debian\shimx64.efi. N’utilisez pas des chemins Linux comme /boot/efi/... pour l’option -l.

5) Should I point to shim or grub?

Si Secure Boot est activé (ou peut l’être plus tard), pointez vers shimx64.efi. Si vous êtes certain que Secure Boot restera désactivé, GRUB direct peut suffire.

6) My system boots after I set BootNext, but not after a normal reboot. Why?

BootNext est une substitution pour un seul démarrage. Votre BootOrder persistant préfère toujours autre chose (PXE, shell, un autre disque). Corrigez BootOrder (Task 16).

7) efibootmgr can list entries but can’t create them. What gives?

La lecture des variables peut fonctionner alors que les écritures échouent, particulièrement en cas d’épuisement de quota NVRAM ou de restrictions d’écriture du firmware. Vérifiez les logs (Task 9) et envisagez le boot de secours si les écritures ne tiennent pas.

8) Is it safe to delete old Boot#### entries to free NVRAM?

Oui si vous savez ce que c’est. Supprimez seulement des entrées qui pointent clairement vers des disques inexistants ou d’anciens installateurs. Dans des environnements multi-OS, supprimer la mauvaise entrée est la façon d’acheter un second incident.

9) What if there are multiple ESPs?

Choisissez-en une par politique de disque de démarrage et soyez cohérent. Le firmware peut préférer l’ESP du premier disque énuméré. L’approche la plus sûre est : gardez l’ESP primaire sur le disque de démarrage principal et assurez-vous que votre entrée y pointe.

10) Does copying shim to BOOTX64.EFI replace the need for NVRAM entries?

Souvent cela fonctionne comme filet de sécurité, mais cela dépend du firmware. Traitez-le comme de la résilience, pas comme un substitut aux entrées NVRAM correctes.

Conclusion : étapes suivantes pour éviter une récidive

Si votre entrée UEFI Debian 13 a disparu, la réparation la plus rapide et fiable n’est pas un lancer de dés. C’est une boucle serrée :

1. Démarrez en mode UEFI, confirmez que efivars fonctionne.
2. Montez l’ESP et vérifiez que les fichiers du chargeur existent.
3. Réinstallez shim/GRUB seulement si les fichiers manquent.
4. Recréez l’entrée NVRAM avec efibootmgr, puis définissez BootOrder.
5. Ajoutez un chargeur de secours à \EFI\BOOT\BOOTX64.EFI si la plateforme a l’habitude d’oublier.

Faites une chose de plus après être revenu en ligne : notez précisément la commande efibootmgr qui a fonctionné pour ce modèle de matériel, incluant disque et partition. Le vous futur remerciera le vous présent, et le vous présent est étonnamment difficile à planifier.