Le mot‑clé principal GRUB2 wiederherstellen est central lorsque un système ne démarre plus après un changement UEFI/BIOS ou en raison d’une perte de la configuration du chargeur d’amorçage. Dans cet article, les administrateurs, ingénieurs systèmes et opérateurs trouveront un guide pratique, étape par étape, pour le diagnostic, la réparation et la vérification — incluant les causes typiques, les risques et les stratégies de repli.
Pourquoi la perte de démarrage ? Causes expliquées brièvement
Avant d’entrer dans la pratique : il est utile de connaître les causes fréquentes afin que la réparation RESTe ciblée. Les trois catégories principales sont les modifications de firmware, les problèmes de partitionnement/ESP et les erreurs d’initramfs/décryptage.
1. Changement de mode UEFI/BIOS
UEFI (Unified Extensible Firmware Interface) est l’interface de firmware moderne ; BIOS ou Legacy désigne l’ancien procédé d’amorçage basé sur MBR. Un passage de l’UEFI au Legacy ou l’inverse peut invalider les entrées d’amorçage dans le firmware (NVRAM), car les systèmes UEFI s’appuient sur une EFI System Partition (ESP) contenant des fichiers .efi, tandis que le Legacy GRUB attend le MBR ou une partition BIOS‑Boot.
2. Partition EFI System (ESP) corrompue ou incorrecte
L’ESP est une petite partition FAT32 avec le type GPT EFI System (ef00). Si elle est supprimée, écrasée par Windows ou montée de façon incorrecte, les binaires GRUB‑EFI (/EFI/<Vendor>/grubx64.efi) font défaut et le système ne démarre pas.
3. Initramfs, root chiffré ou inadéquation du kernel
GRUB charge le noyau et l’initramfs (Initial RAM Filesystem). Si l’initramfs ne contient pas les bons modules pour LVM/LUKS ou les systèmes de fichiers, le démarrage après GRUB échoue. De même, une mise à niveau du kernel sans régénération de l’initramfs sur des volumes root chiffrés empêche leur déchiffrement.
Préparation : prérequis, risques et outils nécessaires
Avant d’intervenir, vérifiez : disposez‑vous d’un environnement de secours (Live‑USB), d’un accès au réglage du firmware, de sauvegardes de l’ESP et, si besoin, des en‑têtes LUKS ? Outils : une distribution Live à jour avec grub-install/grub‑efi, efibootmgr, lsblk, blkid, parted ou gdisk, mount, chroot, et pour les environnements RHEL‑/CentOS dracut.
Risques importants :
- Écrasement supplémentaire de l’ESP rendant inutilisables d’autres systèmes d’exploitation (Windows).
- Absence de sauvegardes des en‑têtes LUKS pour un root chiffré — dans ce cas la RESTauration est nettement plus complexe.
- Mauvais dispositif cible lors de grub-install (p. ex. une partition au lieu du disque entier) pouvant endommager le périphérique de démarrage.
Diagnostic : vérifier l’état du système (Live‑USB)
Commencez avec un Live‑USB (idéalement la même architecture : x86_64). Montez les disques en lecture seule pour l’analyse initiale.
Commandes de vérification importantes et leur signification
Vue des partitions et des périphériques :
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABELTypes de partition et codes GPT :
sudo parted -lMarquage ESP/EFI et UUID :
sudo blkid | grep -i efi
# oder gezielt
sudo lsblk -f /dev/nvme0n1p1Entrées EFI dans le firmware (NVRAM) :
sudo efibootmgr -vSi efibootmgr échoue : le firmware est peut‑être démarré en mode BIOS/Legacy ou efivarfs n’est pas monté. Vérifiez /sys/firmware/efi/exists — si ce répertoire existe, l’environnement Live fonctionne déjà en mode UEFI.
[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy/BIOS mode"Scénarios de RESTauration : étape par étape
Nous distinguons les trois cas pratiques les plus courants et exécutons pour chacun les étapes nécessaires : (A) UEFI : réinstaller GRUB‑EFI, (B) BIOS/Legacy : installer GRUB dans le MBR, (C) changement UEFI↔Legacy ou NVRAM défectueux : Removable‑Fallback.
A. UEFI : Réinstaller GRUB2 (cas standard)
Objectif : écrire les binaires EFI sur la ESP, créer ou corriger l’entrée NVRAM, générer grub.cfg.
- Démarrez l’environnement live en mode UEFI (important pour efibootmgr).
- Montez la racine, /boot et la ESP. Remplacez /dev/sdXn par vos périphériques.
sudo mount /dev/sdX2 /mnt # root-Partition
sudo mount /dev/sdX1 /mnt/boot/efi # EFI System Partition, FAT32
# Falls /boot eine eigene Partition hat:
# sudo mount /dev/sdX3 /mnt/boot
# Bind-Mounts für chroot
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
Chroot, afin que grub-install s’exécute dans le contexte du système (important pour les chemins spécifiques à la distribution).
sudo chroot /mnt /bin/bash
# innerhalb des chroots prüfen
mount | grep efi
Installer GRUB pour UEFI :
# Beispiel für x86_64-UEFI auf Debian/Ubuntu/Fedora
grub-install --target=x86_64-efi --efi-directory=/boot/efi
--bootloader-id=GRUB --recheck --no-nvram
# --no-nvram verhindert Änderungen am NVRAM; nutzen Sie es nur bei Bedarf
Pourquoi cela fonctionne : grub-install crée le fichier binaire .efi sur la ESP (p. ex. /boot/efi/EFI/GRUB/grubx64.efi) et crée éventuellement une entrée NVRAM. L’opération peut échouer si le paquet grub‑efi n’est pas installé ou si l’architecture ne correspond pas (i386 vs x86_64).
Générez la configuration :
# Debian/Ubuntu
update-grub
# RedHat/CentOS
grub2-mkconfig -o /boot/grub2/grub.cfg
Si efibootmgr ne peut pas écrire l’entrée de démarrage, placez le fichier de secours en „removable“ (bootx64.efi) :
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
# BIOS/UEFI-Fallback für viele Firmware-Implementierungen
Quittez le chroot et démontez proprement :
exit
sudo umount -l /mnt/dev /mnt/proc /mnt/sys /mnt/run
sudo umount /mnt/boot/efi
sudo umount /mnt
B. Legacy BIOS : installer GRUB dans le MBR
Si le système doit démarrer en mode Legacy (p. ex. matériel ancien), vous devez écrire GRUB classiquement dans le MBR.
# Vorbereitungen wie oben: mount /mnt, chroot
# Install GRUB to MBR (example /dev/sda)
grub-install --target=i386-pc /dev/sda --recheck
grub-mkconfig -o /boot/grub/grub.cfg
À noter : les tables de partition GPT modernes nécessitent éventuellement une petite partition BIOS‑Boot (type ef02 avec gdisk) pour GRUB‑Stage2. Sans cette partition, grub-install échouera sur des disques GPT si le démarrage doit se faire en mode BIOS.
C. Changement UEFI↔Legacy, NVRAM défectueux ou menu de firmware limité
Certaines firmwares n’autorisent plus d’entrées NVRAM (trop nombreuses ou défectueuses). Dans ce cas, le chemin de démarrage « removable » est pertinent : placer le binaire EFI installé sous /EFI/BOOT/BOOTX64.EFI. C’est robuste, mais cela peut écraser les chargeurs d’amorçage d’autres OS.
# innerhalb des chroot
mkdir -p /boot/efi/EFI/BOOT
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
Cas particuliers et dépannage
Restaurer GRUB2 avec root chiffré (LUKS)
Pour un root chiffré avec LUKS (LUKS ist die Linux Unified Key Setup) vous devez, dans le chroot, ouvrir le volume LUKS afin que /mnt contienne effectivement le root correct. Important : avez-vous sauvegardé les en-têtes LUKS ? Sans les en-têtes, une RESTauration est très lourde.
# LUKS-Container öffnen (im Live-System, vor dem Mounten)
sudo cryptsetup luksOpen /dev/sdX2 cryptroot
sudo mount /dev/mapper/cryptroot /mnt
Après l’installation de grub, régénérez l’initramfs (l’initramfs est le système de fichiers RAM précoce qui fournit les modules pour LVM/LUKS) :
# Debian/Ubuntu
update-initramfs -u -k all
# RedHat/CentOS
dracut -f
Si la mauvaise combinaison noyau‑initramfs est installée (p. ex. noyau ancien), le démarrage après GRUB peut échouer lors de la phase initramfs.
Erreur : grub-install signale „cannot find EFI directory“ ou „secure boot“
Causes et solutions :
- Partition EFI non en FAT32 ou non montée : montez‑la sous /boot/efi.
- Secure Boot activé : soit désactiver temporairement le Secure Boot, soit utiliser des binaires signés (shim). Shim est un petit programme signé qui peut charger grubx64.efi non signé si il est autorisé dans le MOK‑Store (Machine Owner Key).
- Paquet manquant : sur Debian/Ubuntu installez grub‑efi‑amd64 et efibootmgr ; sur les systèmes basés RHEL grub2‑efi‑x64.
efibootmgr n’écrit pas dans le NVRAM ou les entrées disparaissent
Plusieurs raisons : bugs du firmware, protection en écriture du NVRAM ou saturation. Vérifiez si le firmware supprime les entrées. En alternative : utiliser le chemin removable ou définir manuellement l’ordre de démarrage du firmware dans le setup UEFI.
Validation : comment vérifier que la RESTauration a réussi
Redémarrez le système et utilisez la sélection de démarrage du firmware pour tester la nouvelle entrée. Pour vérification depuis le système en cours :
# prüft ob System im UEFI-Modus gebootet hat
[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy boot"
# efibootmgr zeigt aktive Eintraege
sudo efibootmgr -v
# prüft gültige grub.cfg
sudo test -f /boot/grub/grub.cfg && echo "grub.cfg vorhanden"Surveillez, lors du premier démarrage, les messages système (journalctl -b) et soyez attentif aux étapes qui échouent lors du déchiffrement du root ou du montage des volumes LVM.
Liste de contrôle pratique : playbook de récupération rapide
- Fournir un Live‑USB avec l’architecture adéquate (prendre en compte le mode UEFI/BIOS).
- Sauvegardes importantes : instantané de l’ESP, en‑têtes LUKS, sauvegarder la configuration de Grub.
- Diagnostic : lsblk, parted, blkid, efibootmgr — vérifiez si l’ESP est présent et en FAT32.
- Monter, chroot et installation de grub conformément au mode cible (UEFI/BIOS).
- Régénérer l’initramfs en cas de modifications LUKS/LVM/noyau.
- Si efibootmgr ne fonctionne pas : écrire l’EFI removable (BOOTX64.EFI).
- Redémarrage et validation : menu de démarrage du firmware, journalctl -b, vérifier l’état LVM/LUKS.
Pièges typiques et comment les éviter
Erreur 1 : monter la mauvaise partition (Windows ESP au lieu de Linux ESP). Prévenir : utiliser l’UUID plutôt que le nom de périphérique (blkid fournit les UUID). Erreur 2 : mauvaise architecture du fichier .efi (i386 vs x86_64). Prévenir : utiliser l’image live de l’architecture cible. Erreur 3 : NVRAM pleine ou instable. Prévenir : prévoir un fallback removable.
Stratégie de rollback et prévention
Avant toute modification, effectuez une sauvegarde :
# ESP als Image sichern
sudo dd if=/dev/sdX1 of=esp-backup-$(date +%F).img bs=4M status=progress
# LUKS-Header sichern
sudo cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file luks-header-$(date +%F).bin
Accès d’urgence : disposez d’une console de secours et d’une option de démarrage alternative (p. ex. network boot, PXE ou KVM physique). Documentez les sorties originales d’efibootmgr afin de pouvoir reconstituer les entrées si nécessaire.
Quand une réinstallation du bootloader n’aide pas
Il existe des cas où la seule restauration de GRUB ne suffit pas : défaillance matérielle du support de démarrage, en-têtes LUKS manquants ou système de fichiers racine corrompu. En présence d’erreurs disque, exécutez d’abord des tests SMART et des vérifications du système de fichiers ; ce n’est qu’une fois l’intégrité physique assurée que vous entamez les réparations du bootloader.
# SMART-Test
sudo smartctl -a /dev/sda
# Dateisystemcheck ext4 (nur ungemountet)
sudo fsck.ext4 -f /dev/sdX2
Brèves remarques sur les différences entre distributions
Les distributions nomment les chemins différemment : Debian/Ubuntu utilise /boot/grub, RedHat/CentOS /boot/grub2 et des commandes distinctes pour générer la configuration (update-grub vs grub2-mkconfig). Lors des travaux en chroot, faites attention aux chemins spécifiques à la distribution et aux paquets installés.
Restaurer GRUB2 : script de recovery automatisé et audit
Dans des environnements étendus, un script de recovery vérifiable et idempotent est recommandé ; il ne doit effectuer que le diagnostic et la préparation des points de montage — l’installation effective de grub doit être exécutée manuellement ou validée via ticketing. L’exemple ci‑dessous montre un bloc de vérification sûr qui détecte l’ESP et le mode, et génère des messages pour le ticketing.
#!/bin/bash
set -euo pipefail
# Simple pre-checks before manual recovery actions
if [ -d /sys/firmware/efi ]; then
echo "System already booted in UEFI mode"
else
echo "Live-Umgebung ist Legacy/BIOS-mode"
fi
ESP=$(blkid -t PARTLABEL="EFI System" -o device || true)
if [ -z "$ESP" ]; then
echo "Keine ESP gefunden: blkid output:"; blkid | sed -n '1,200p'
exit 2
fi
UUID=$(blkid -s UUID -o value "$ESP")
echo "ESP device: $ESP UUID: $UUID"
# create a small audit file for ticketing
mkdir -p /var/log/grub-recovery-audit
echo "$(date -Iseconds) - ESP:$ESP UUID:$UUID UEFI:$( [ -d /sys/firmware/efi ] && echo yes || echo no)"
>> /var/log/grub-recovery-audit/recovery.log
Pourquoi c’est utile : le script ne modifie rien sur le système, produit des données de diagnostic reproductibles et contraint les administrateurs à valider manuellement les étapes sensibles d’installation de grub.
Secure Boot, shim et workflow MOK
Lorsque Secure Boot est actif, grub‑efi ne peut fonctionner que si les binaires .efi sont signés ou si shim est utilisé. Shim est un petit bootloader reconnu par le firmware qui, une fois le Machine Owner Key (MOK) enregistré dans le magasin du firmware, charge ensuite des binaires GRUB non signés.
# MOK importieren (im installierten System oder chroot)
sudo mokutil --import /path/to/public_key.der
# reboot and enroll the key in the MOK manager during boot
Si vous devez signer vous‑même des binaires, utilisez sbsign ou sign-file (Kernel/GRUB). Attention : un workflow MOK incorrect peut empêcher complètement le système de démarrer ; testez toujours les modifications d’abord dans une VM.
Tests et déploiement en environnement d’entreprise
Mettez en place des lignes de test : un cycle de validation automatisé avec qemu/kvm vérifie si une image ESP nouvellement créée et un grubx64.efi démarrent dans la simulation du firmware. Cela réduit le risque lors du déploiement sur plusieurs serveurs.
# Beispiel: schnelles Boot-Test-Image mit qemu
qemu-system-x86_64 -m 1024 -bios /usr/share/ovmf/OVMF.fd -hda test-disk.img -boot d
Dans de grandes installations, les modifications de récupération doivent être gérées via la gestion de configuration et le change control (par ex. des playbooks Ansible qui effectuent uniquement des vérifications de validation). Prévoyez une fenêtre de rollback définie au cas où des différences de firmware apparaîtraient après la mise à jour et entraîneraient des effets imprévus.
Supervision, alertes et prévention
Automatisez les alertes précoces : surveillez la dernière réussite de démarrage avec un agent, vérifiez après les mises à jour du noyau si la régénération de l’initramfs a réussi et validez les entrées de démarrage après les mises à jour du firmware. Un dépôt d’instantanés ESP facilite la restauration rapide.
Conclusion : systématique, sûr, documenté
La restauration de GRUB2 réussit de manière fiable si vous procédez de façon structurée : diagnostic d’abord, puis réparation ciblée pour UEFI ou BIOS, régénération de l’initramfs pour un root chiffré et enfin validation. Sauvegardez des instantanés ESP et les en-têtes LUKS avant toute intervention. Pour des environnements productifs, un playbook de récupération défini, l’automatisation des tests et des vérifications régulières de la politique du firmware sont recommandés.
Si vous rédigez une documentation interne : consignez précisément les UUID des périphériques, la version du firmware et l’ordre exact des étapes réalisées. Ces informations font gagner du temps lors d’incidents récurrents et aident lors de l’analyse de la cause racine.
Liens internes complémentaires (exemples) : liez ici vers les directives sur les sauvegardes des disques chiffrés, les politiques de mise à niveau du noyau ou le playbook de reprise après sinistre de votre organisation, afin d’assurer un processus opérationnel complet.
Pour ce sujet, les guides « Restauration du chargeur de démarrage UEFI » et « Guide d’installation de GRUB » sont également importants. Cet article place ces aspects de manière claire et montre ce qui compte au quotidien.