Ce que grub rescue> signifie réellement

GRUB a plusieurs « humeurs ». Le mode normal lit sa configuration, propose un menu (ou démarre immédiatement), puis passe la main au noyau.
grub rescue> est le shell d’urgence allégé. Vous êtes ici parce que l’image core de GRUB a été chargée, mais elle ne peut pas charger
ce dont elle a besoin ensuite — généralement des modules et la configuration — parce qu’elle ne trouve pas le système de fichiers ou le chemin attendus.

L’échec entre presque toujours dans l’une de ces catégories :

• Mauvaise référence de disque/partition (ordre des périphériques changé, numérotation NVMe modifiée, ordre de démarrage du BIOS changé).
• /boot manquant ou déplacé (redimensionnement de partition, partition supprimée, réinstallation, « nettoyage »).
• Fichiers GRUB corrompus (mise à jour partielle, corruption du disque, mauvais montage lors d’une réinstallation).
• Incompatibilité UEFI vs legacy (installé d’une manière, le firmware essaye maintenant l’autre).
• Complexité Encryption/LVM/RAID (GRUB ne peut pas lire le volume sans les bons modules ou la bonne organisation).

Votre hypothèse la plus sûre : le système d’exploitation est toujours sur le disque, mais les pointeurs du chargeur d’amorçage sont obsolètes. Traitez cela comme
une carte brisée, pas une ville en ruine.

Une vérité opérationnelle : quand les gens paniquent ici, ils commencent à « réparer » les partitions. C’est comme ça qu’on transforme un problème de démarrage
en un problème de récupération de données. Ne le faites pas.

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

Premier : identifier le type de démarrage (UEFI ou BIOS hérité)

Cela détermine la cible de réparation correcte. En UEFI, vous réparez la partition système EFI (ESP) et l’entrée NVRAM.
En BIOS hérité, vous réparez le MBR / la zone de démarrage BIOS et l’installation GRUB du disque.

• Si vous pouvez entrer dans la configuration du firmware : liste-t-il « ubuntu » comme option de démarrage UEFI ? Si oui, installation probablement en UEFI.
• Depuis un live USB : la présence de /sys/firmware/efi signifie que l’environnement live a démarré en mode UEFI.

Deuxième : trouver le vrai système de fichiers racine et l’endroit où se trouve /boot

Vos commandes de réparation doivent pointer vers le système Ubuntu réellement installé. Montage incorrect = réparation réussie du mauvais système.
Identifiez les partitions par UUID et type de système de fichiers, pas par « c’est généralement sda2 ».

Troisième : confirmer s’il s’agit d’un problème de pointeur ou d’un problème disque

Si le disque est en train de lâcher, réinstaller GRUB ressemble à repeindre un navire qui prend l’eau. Vérifiez SMART pour des signes évidents et scannez
les journaux du noyau depuis l’environnement live pour des erreurs d’E/S. Si vous voyez des échecs de lecture, arrêtez-vous et priorisez les données.

Fourche décisionnelle (rapide)

• Vous voyez vos partitions Linux et pouvez les monter : probablement une réinstallation de GRUB / régénération de la config résoudra le problème.
• Vous ne pouvez pas monter le système de fichiers : réparation du système de fichiers et/ou dépannage du stockage d’abord.
• Vous avez LUKS + LVM + RAID : ouvrez et assemblez les couches soigneusement, puis réinstallez GRUB depuis un chroot.

Faits intéressants et petite histoire (parce que ça compte)

1. GRUB signifie « GRand Unified Bootloader », conçu à l’origine pour unifier le démarrage entre différents OS et systèmes de fichiers quand c’était un désordre.
2. GRUB2 n’est pas « simplement la version 2 » ; c’est une réécriture majeure avec des sémantiques de configuration et un chargement modulaire différents.
3. L’« image core » est volontairement minuscule — c’est ce que le firmware charge d’abord, et elle tente de récupérer des modules depuis le disque. Quand cette récupération échoue, vous atterrissez en mode rescue.
4. UEFI a changé la façon de démarrer : au lieu de code de démarrage dans le MBR, le firmware charge un exécutable EFI depuis l’ESP. C’est pourquoi les étapes de réinstallation diffèrent.
5. Le comportement par défaut d’Ubuntu suppose désormais souvent l’UEFI sur le matériel moderne, mais de nombreuses flottes utilisent encore le BIOS hérité pour compatibilité ou inertie.
6. L’instabilité des noms de disque est réelle : les périphériques NVMe peuvent renuméroter selon l’ordre d’énumération ; les contrôleurs USB/SATA peuvent réordonner. Les UUID existent parce que les humains n’aiment pas les surprises.
7. Historiquement, GRUB était apprécié pour sa connaissance des systèmes de fichiers comparé aux anciens chargeurs incapables de lire ext* sans aide.
8. GRUB moderne peut lire LUKS1 dans certains cas, mais le chiffrement de disque complet avec des défauts récents (LUKS2, réglages PBKDF) peut toujours compliquer l’amorçage précoce.
9. « Unknown filesystem » dans GRUB signifie souvent « module manquant », pas nécessairement que le système de fichiers a disparu — GRUB est modulaire, et le mode rescue charge moins de modules.

Une idée paraphrasée à garder en tête (et dans votre checklist d’incident) : l’espoir n’est pas une stratégie. — attribuée à John C. Maxwell dans les cercles ops.
Quelle que soit l’origine, c’est exact : mesurer d’abord, puis changer les choses.

Tâches pratiques : commandes, sorties, décisions (le cœur du sujet)

Ces tâches supposent que vous travaillez depuis un live USB Ubuntu (même version majeure de préférence, mais pas obligatoire), et votre objectif est
le changement minimal. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision suivante.

Tâche 1 : Confirmer si l’environnement live a démarré en UEFI

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Signification : Si vous voyez « UEFI mode », vous devez réparer le chemin de démarrage EFI et utiliser grub-install --target=x86_64-efi.
Si « Legacy BIOS mode », installez GRUB dans le MBR du disque avec --target=i386-pc.
Décision : Si cela ne correspond pas à la manière dont le système a été installé, redémarrez le live USB et sélectionnez le bon mode de démarrage dans le firmware.

Tâche 2 : Énumérer les périphériques bloc et les systèmes de fichiers

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS
NAME         SIZE TYPE FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
nvme0n1    953.9G disk
├─nvme0n1p1   512M part vfat   FAT32       3C21-1A7B
├─nvme0n1p2     2G part ext4   1.0         2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b
└─nvme0n1p3 951.4G part crypto_LUKS 2     9d8d5b6a-8f1c-4a44-9b3c-3b2c9a1f0caa

Signification : Vous recherchez : l’ESP (vfat ~100–1024Mo), peut-être un /boot séparé (ext4),
et le système racine (ext4/xfs/btrfs) ou un conteneur chiffré.
Décision : Notez les noms de périphériques et les UUID. Ne commencez pas à « réparer » tant que vous ne savez pas quelle partition est laquelle.

Tâche 3 : Si chiffré, ouvrir LUKS proprement (ne pas improviser)

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

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS /dev/mapper/cryptroot
NAME      TYPE FSTYPE      MOUNTPOINTS
cryptroot crypt LVM2_member

Signification : Le périphérique déchiffré est un PV LVM (agencement Ubuntu courant).
Décision : Activez ensuite LVM. Si cryptsetup échoue, arrêtez-vous et vérifiez que vous êtes sur la bonne partition et que le disque est sain.

Tâche 4 : Activer les volumes LVM et trouver la racine

cr0x@server:~$ sudo vgscan --mknodes
  Found volume group "ubuntu-vg" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "ubuntu-vg" now active

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS | grep -E "ubuntu--vg|lv|root|swap" || true
├─ubuntu--vg-root  200G ext4
└─ubuntu--vg-swap    8G swap

Signification : Les volumes logiques sont maintenant visibles. La racine est probablement ubuntu--vg-root.
Décision : Montez la racine, puis montez /boot et l’ESP si nécessaire.

Tâche 5 : Monter le système installé correctement (root, boot, ESP)

cr0x@server:~$ sudo mount /dev/mapper/ubuntu--vg-root /mnt

cr0x@server:~$ sudo mkdir -p /mnt/boot /mnt/boot/efi

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

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

Signification : findmnt est votre vérification de cohérence. Si vous montez les mauvais éléments, la réparation peut « réussir »
et continuer à ne pas démarrer.
Décision : Si /mnt/boot/efi est absent dans une installation UEFI, vous n’êtes pas prêt à réinstaller GRUB.

Tâche 6 : Vérifier les problèmes évidents de disque ou de système de fichiers avant d’écrire des données de démarrage

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 30 09:14:12 2025] nvme nvme0: I/O 17 QID 6 timeout, aborting
[Mon Dec 30 09:14:12 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Signification : Les erreurs de lecture ou les timeouts signifient que vous devriez faire une pause. La réparation du démarrage écrit des données ; si le disque se détériore, vous jouez avec la récupération.
Décision : Si vous voyez des erreurs d’E/S, priorisez l’imagerie/sauvegarde. Si les journaux sont propres, poursuivez.

Tâche 7 : Identifier comment le système installé s’attend à monter les disques (vérification des UUID)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b /boot ext4 defaults 0 2
UUID=3C21-1A7B /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-root / ext4 defaults 0 1

Signification : Si fstab référence des UUID qui n’existent plus, le démarrage peut échouer plus tard même après la réparation de GRUB.
Décision : Si des UUID sont incohérents, corrigez-les maintenant (avec précaution). Mais n’inventez pas d’UUID — utilisez blkid.

Tâche 8 : Examiner la configuration GRUB installée et identifier la cible

cr0x@server:~$ sudo ls -l /mnt/boot/grub
total 12
-rw-r--r-- 1 root root  144 Dec 29 18:12 grub.cfg
drwxr-xr-x 2 root root 4096 Dec 29 18:12 x86_64-efi
drwxr-xr-x 2 root root 4096 Dec 29 18:12 fonts

Signification : La présence de x86_64-efi suggère une installation UEFI. Les installations legacy auront typiquement i386-pc.
Décision : Adaptez votre grub-install --target à cette réalité, pas à votre supposition.

Tâche 9 : Bind-monter les répertoires système et chroot (la bonne méthode)

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/#

Signification : Vous opérez maintenant « à l’intérieur » du système installé, où les outils GRUB s’attendent à fonctionner.
Décision : Si le chroot échoue ou que des outils manquent, il se peut que vous ayez monté la mauvaise racine, ou que l’installation soit incomplète.

Tâche 10 : Réinstaller GRUB en UEFI (chemin recommandé pour Ubuntu 24.04 sur matériel moderne)

cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Signification : Le binaire GRUB EFI et les fichiers de support ont été installés sur l’ESP, et les entrées NVRAM peuvent être mises à jour.
Décision : Si cela renvoie une erreur « cannot find EFI directory », votre ESP n’est pas monté sur /boot/efi.
Corrigez les montages et relancez.

Tâche 11 : Réinstaller GRUB en BIOS hérité (quand vous êtes vraiment en mode BIOS)

cr0x@server:~$ grub-install --target=i386-pc --recheck /dev/nvme0n1
Installing for i386-pc platform.
Installation finished. No error reported.

Signification : Le code de démarrage GRUB a été écrit dans la zone de démarrage du disque. Cela ne cible pas une partition comme /dev/nvme0n1p2.
Décision : Si vous n’êtes pas sûr du disque à partir duquel le firmware démarre, arrêtez-vous et confirmez. Installer sur le mauvais disque est un classique.

Tâche 12 : Régénérer la configuration GRUB et initramfs (les configs obsolètes sont un vilain coupable)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Signification : Cela reconstruit initramfs (important pour LUKS/LVM/RAID) et s’assure que les entrées du menu GRUB pointent vers de vrais noyaux.
Décision : Si update-grub ne trouve pas de noyaux, votre montage /boot est incorrect ou vide.

Tâche 13 : Vérifier les entrées de démarrage UEFI (quand le firmware « oublie » ubuntu)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI: Built-in EFI Shell
Boot0002* ubuntu HD(1,GPT,2f3a...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Signification : Vous avez une entrée ubuntu pointant sur shimx64.efi (commun quand Secure Boot est activé).
Décision : Si aucune entrée ubuntu n’existe, créez-en une ou réinstallez GRUB en vous assurant que --bootloader-id est défini.

Tâche 14 : Si vous êtes bloqué dans grub rescue> sans live USB, effectuez un démarrage temporaire

Ce n’est pas « la réparation ». C’est « me permettre d’atteindre un vrai OS pour le réparer correctement ». Dans grub rescue> vous disposez de commandes limitées.
Votre but est de trouver la partition contenant /boot/grub, définir root et prefix, charger normal, et démarrer.

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

cr0x@server:~$ ls (hd0,gpt2)/
lost+found/ boot/ vmlinuz initrd.img

cr0x@server:~$ set root=(hd0,gpt2)

cr0x@server:~$ set prefix=(hd0,gpt2)/boot/grub

cr0x@server:~$ insmod normal

cr0x@server:~$ normal

Signification : Vous avez manuellement indiqué à GRUB le bon emplacement. Si cela fonctionne, vous obtiendrez le menu GRUB normal.
Décision : Démarrez le système, puis réinstallez GRUB de façon permanente depuis Ubuntu (ou depuis un live USB) pour éviter que cela ne se reproduise.

Tâche 15 : Confirmer que le système installé voit les disques de façon cohérente (UUIDs et by-id)

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 15 Dec 30 09:22 2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Dec 30 09:22 3C21-1A7B -> ../../nvme0n1p1

Signification : Les mappages UUID existent. C’est sur ça que repose un démarrage stable.
Décision : Si votre configuration GRUB ou fstab utilise des noms de périphériques bruts (par ex. /dev/nvme0n1p2), envisagez de passer aux UUID.

Tâche 16 : Sortir proprement et redémarrer (éviter de laisser des montages)

cr0x@server:~$ exit
exit

cr0x@server:~$ for i in /run /sys /proc /dev/pts /dev; do sudo umount -l /mnt$i; done

cr0x@server:~$ sudo umount -l /mnt/boot/efi /mnt/boot /mnt

cr0x@server:~$ sudo reboot

Signification : Vous avez démonté dans l’ordre inverse. Cela réduit les risques d’états incohérents, surtout avec des couches LUKS/LVM.
Décision : Si le redémarrage retombe en rescue, consultez la table des erreurs et vérifiez le mode de démarrage + la cible disque correcte.

Blague #1 : GRUB rescue est comme une alerte de pager — vous n’en recevez pas quand tout va bien, mais cela signifie que le système vous parle encore.

Trois mini-récits en entreprise (comment ça foire en vrai)

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

Une entreprise gérait une petite flotte de serveurs Ubuntu sur du matériel identique. Le modèle mental était rassurant : même modèle, mêmes réglages BIOS,
même agencement de disque, tout pareil. Quelqu’un a remplacé un NVMe défaillant sur un nœud, l’a réimagé, et est passé à autre chose.

Au redémarrage suivant, le serveur est tombé dans grub rescue>. La personne d’astreinte a supposé que c’était « comme la fois d’avant » et a immédiatement lancé
une grub-install en mode BIOS depuis un live USB. Cela a « marché » dans le sens où du code de démarrage a été écrit.
Cela n’a pas marché dans le sens où le serveur ne démarré toujours pas.

Le vrai problème : ce nœud avait été installé en UEFI, mais le live USB avait été démarré en mode legacy, et le firmware avait discrètement
changé son ordre de démarrage après le remplacement du disque. Ils réparaient la mauvaise couche. Après quelques cycles, ils avaient un disque
contenant des artefacts des deux modes et une liste d’entrées firmware confuse.

La réparation fut ennuyeuse : démarrer le live USB en UEFI, monter l’ESP sur /boot/efi, réinstaller GRUB avec la cible UEFI,
puis utiliser efibootmgr pour confirmer une entrée sane. La leçon n’était pas « UEFI est compliqué ». La leçon était : votre environnement de réparation
doit correspondre au mode d’amorçage installé, sinon votre « correctif » n’est que de l’écriture confiante de code de démarrage aléatoire.

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

Une autre organisation avait pour habitude d’optimiser finement les agencements de disque. Quelqu’un a décidé que des partitions /boot séparées étaient « legacy »
et a consolidé /boot dans le système racine lors d’un rafraîchissement de stockage. Ils ont aussi activé le chiffrement de disque complet
avec des valeurs par défaut plus modernes. C’était propre. Moins de partitions, moins de montages, moins de choses à casser. Non ?

Puis une mise à jour est arrivée et un sous-ensemble de machines a commencé à tomber dans GRUB rescue. Le problème sous-jacent n’était pas la mise à jour du noyau.
C’était que l’environnement précoce du chargeur d’amorçage était devenu moins capable : GRUB ne pouvait pas lire de façon fiable la disposition racine chiffrée
dans cette configuration, et il n’y avait pas de /boot non chiffré pour servir de zone de transit simple.

L’équipe a d’abord traité cela comme « GRUB est cassé ». Ils ont réinstallé GRUB, régénéré les configs, même recréé les entrées EFI. Certains nœuds sont revenus,
d’autres non, et la variance était le pire — parce que la variance entraîne une escalade.

La solution long terme a été de standardiser : garder un petit /boot non chiffré (et bien sûr une ESP pour l’UEFI) pour cette classe de serveurs,
documenté et testé. L’« optimisation » avait supprimé une marge de sécurité. En production, les marges de sécurité ne sont pas du désordre.
Ce sont vos soirées tranquilles futures.

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

Une troisième équipe avait une habitude qui paraissait fastidieuse : chaque fois qu’ils touchaient aux partitions ou remplaçaient un disque, ils capturaient une base :
lsblk -f, blkid, efibootmgr -v (sur UEFI), plus une copie de /etc/fstab et
/boot/grub/grub.cfg. Ils stockaient ça avec le journal de changement. Pas glamour. Très efficace.

Quand un serveur est tombé en grub rescue> après une fenêtre de maintenance, la personne d’astreinte n’a pas eu à deviner si la machine était
UEFI ou legacy, si /boot était séparé, ou quel UUID appartenait à l’ESP. Ils ont comparé la sortie actuelle avec la baseline
et ont immédiatement vu que l’UUID de l’ESP avait changé après un échange de disque, tandis que fstab faisait toujours référence à l’ancien.

La réparation a pris quelques minutes : monter la bonne ESP, mettre à jour fstab pour correspondre, réinstaller GRUB, régénérer la config, redémarrer.
Aucun outil de partitionnement n’a été ouvert. Pas de prouesses nocturnes. Personne n’a appris une nouvelle compétence de récupération de fichiers.

Blague #2 : La meilleure réponse d’incident est celle où vous tapez surtout cat et affichez un air modérément déçu.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptomatique : error: unknown filesystem dans GRUB rescue

• Cause racine : GRUB pointe sur la mauvaise partition, ou il ne peut pas charger le module du système de fichiers en mode rescue.
• Correctif : Dans grub rescue>, utilisez ls pour trouver la partition qui contient réellement /boot/grub.
  Définissez root et prefix, insmod normal, puis démarrez ; par la suite réinstallez GRUB depuis l’OS.

2) Symptomatique : error: file '/boot/grub/i386-pc/normal.mod' not found

• Cause racine : GRUB legacy/BIOS attend des modules i386-pc mais ils sont absents (ou vous utilisez en fait UEFI).
• Correctif : Vérifiez le mode de démarrage et réinstallez GRUB avec la cible correcte. En UEFI, attendez-vous à x86_64-efi.

3) Symptomatique : le système démarre en rescue après un remplacement de disque, mais les partitions semblent correctes

• Cause racine : L’ordre de démarrage du firmware a changé ; entrée NVRAM UEFI manquante ou pointant vers le mauvais disque.
• Correctif : Démarrez le live USB en mode UEFI, montez l’ESP, lancez la réinstallation GRUB UEFI, puis vérifiez avec efibootmgr -v.

4) Symptomatique : la réinstallation GRUB « réussit » mais rien ne change

• Cause racine : Vous avez monté la mauvaise racine (fréquent quand plusieurs disques existent) ou n’avez pas monté /boot//boot/efi.
• Correctif : Utilisez findmnt -R /mnt et validez le contenu attendu sous /mnt/boot et /mnt/boot/efi avant de chrooter.

5) Symptomatique : après la réparation, le noyau démarre mais aboutit à l’invite initramfs

• Cause racine : UUID de racine incorrect, modules LVM/crypt manquants dans initramfs, ou mauvais crypttab/fstab.
• Correctif : Depuis le chroot, exécutez update-initramfs -u -k all, vérifiez que /etc/crypttab et /etc/fstab correspondent aux UUID actuels.

6) Symptomatique : ne fonctionne que lorsque Secure Boot est activé

• Cause racine : Mauvais binaire EFI choisi (GRUB vs shim), ou composants non signés dans la chaîne.
• Correctif : Réinstallez GRUB avec le chemin shim par défaut d’Ubuntu et confirmez que efibootmgr pointe vers \EFI\ubuntu\shimx64.efi.
  À titre de diagnostic temporaire, désactivez Secure Boot pour confirmer l’hypothèse.

7) Symptomatique : rescue apparu après redimensionnement/déplacement de partition

• Cause racine : Décalage du pointeur embarqué de GRUB (surtout en BIOS legacy) ou système de fichiers déplacé sans réinstaller GRUB.
• Correctif : Réinstallez GRUB sur le disque correct et régénérez la configuration. Évitez de répéter les redimensionnements sans cycle de redémarrage/validation.

8) Symptomatique : rescue après conversion MBR↔GPT ou modification des paramètres du firmware

• Cause racine : Incompatibilité de méthode de démarrage (UEFI attend GPT+ESP ; le BIOS s’attend à du code placé ailleurs).
• Correctif : Choisissez une méthode. Pour Ubuntu 24.04 moderne, privilégiez UEFI+GPT+ESP sauf raison contraire.

Listes de vérification / plan étape par étape (moins de dégâts)

Phase 0 : Sécurité d’abord (2 minutes, économies d’heures)

• Ne lancez pas d’éditeurs de partition à moins de pouvoir énoncer précisément le problème.
• Prenez des photos/captures d’écran des réglages de démarrage du firmware et de la liste des disques si possible.
• Si le système contient des données critiques et que vous voyez des erreurs d’E/S, arrêtez et protégez d’abord les données.

Phase 1 : Identifier le mode de démarrage et la disposition du stockage

1. Démarrez un live USB dans le mode prévu (UEFI ou legacy). Confirmez avec [ -d /sys/firmware/efi ].
2. Exécutez lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS et cartographiez l’ESP, /boot, la racine, et les couches crypto/LVM/RAID.
3. Montez la racine sur /mnt. Montez /boot et /boot/efi s’ils existent.
4. Validez les montages avec findmnt -R /mnt. Confirmez que /mnt/etc et /mnt/boot contiennent de vrais fichiers.

Phase 2 : Réparer depuis un chroot (minimal, déterministe)

1. Bind-montez /dev, /proc, /sys, /run dans /mnt.
2. chroot /mnt.
3. Réinstallez GRUB :
   • UEFI : grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
   • BIOS : grub-install --target=i386-pc --recheck /dev/<disk>
4. Exécutez update-initramfs -u -k all et update-grub.
5. Si UEFI : exécutez efibootmgr -v et confirmez que l’entrée pointe vers le bon chemin.

Phase 3 : Valider et redémarrer proprement

1. Sortez du chroot, démontez dans l’ordre inverse.
2. Redémarrez et confirmez que le démarrage est normal.
3. Après le démarrage : exécutez journalctl -b -0 -p warning pour détecter d’éventuels problèmes de disque ou de montage.

Quand arrêter les « réparations » et escalader vers la récupération de stockage

• SMART montre des secteurs réalloués/pending sur SATA, ou NVMe rapporte des erreurs media.
• dmesg montre des erreurs E/S répétées lors des lectures.
• Le système de fichiers ne monte pas même en lecture seule, ou fsck signale une corruption sévère.

Les chargeurs d’amorçage ne valent pas de se battre jusqu’à la mort. Si le disque meurt, votre priorité est les données, puis la reconstruction.

FAQ

1) grub rescue> signifie-t-il que mes données sont perdues ?

Généralement non. Cela signifie le plus souvent que GRUB ne trouve pas ses modules ou sa configuration. Votre système racine est souvent intact.
Confirmez en montant les partitions depuis un live USB.

2) Quelle est la différence entre réparer depuis grub rescue> et depuis un live USB ?

Depuis grub rescue> vous pouvez parfois démarrer une fois en définissant root et prefix, mais c’est fragile.
Un live USB vous permet de monter le système installé et de réinstaller GRUB correctement.

3) J’ai réinstallé GRUB et ça démarre encore en rescue. Quelle est l’erreur la plus probable ?

Mauvais mode de démarrage (UEFI vs BIOS) ou mauvais montages. Le correctif a « fonctionné » mais a ciblé le mauvais emplacement.
Vérifiez avec findmnt et contrôlez si vous avez monté l’ESP sur /boot/efi.

4) Dois-je utiliser Boot-Repair ou d’autres outils automatisés ?

En dépannage d’urgence, l’automatisation peut aider, mais elle masque aussi les décisions et peut écrire des changements que vous n’aviez pas prévus.
Pour limiter les dégâts en production, procédez manuellement : monter → chroot → réinstaller, et gardez la procédure déterministe.

5) Secure Boot peut-il provoquer grub rescue> ?

Oui, indirectement. Si la chaîne attend shim et des composants signés et que quelque chose pointe vers le mauvais binaire EFI, le firmware peut refuser
de charger l’étape suivante et vous laisser dans un mauvais état. Confirmez que l’entrée de démarrage référence shimx64.efi sur Ubuntu.

6) J’ai LVM et chiffrement. Dois-je réinstaller GRUB différemment ?

Les commandes de réinstallation sont similaires, mais les étapes préalables changent : il faut ouvrir LUKS, activer LVM, et monter la bonne racine/boot/ESP.
Regénérez aussi initramfs afin que l’environnement précoce sache comment déverrouiller et assembler les volumes.

7) Puis-je réparer sans chroot ?

Parfois, mais c’est plus sujet aux erreurs. Le chroot permet aux outils GRUB et initramfs de fonctionner avec les chemins et configurations du système installé.
Cela réduit les accidents du type « j’ai réparé le live USB ».

8) Que faire si efibootmgr n’affiche aucune entrée ubuntu ?

Réinstallez GRUB en mode UEFI avec l’ESP montée sur /boot/efi. Si cela n’ajoute toujours pas d’entrée, vous pouvez en créer une manuellement,
mais vérifiez d’abord l’existence du fichier à /boot/efi/EFI/ubuntu/shimx64.efi ou grubx64.efi.

9) Mon serveur a plusieurs disques. Sur quel disque dois-je installer GRUB ?

Installez sur le disque depuis lequel le firmware démarre. En UEFI, il s’agit surtout de l’ESP et de l’entrée de démarrage utilisée.
En BIOS, installer sur le mauvais MBR de disque est une manière efficace de rester en panne.

10) Après avoir réparé GRUB, pourquoi suis-je tombé dans initramfs au lieu d’avoir l’invite de connexion ?

GRUB a correctement passé la main au noyau, mais le noyau ne peut pas monter la racine (UUID incorrect, modules crypt/LVM manquants, mauvais fstab/crypttab).
Revérifiez les UUID et régénérez initramfs depuis le chroot.

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

Se remettre de grub rescue> consiste surtout en un empilement discipliné : mode firmware, agencement disque, montages, puis réinstallation.
La voie la moins dommageable est aussi la plus ennuyeuse : mesurer, monter correctement, chrooter, réinstaller GRUB avec la bonne cible, régénérer initramfs et la configuration.

Actions pratiques que vous devriez réellement faire après que le système a redémarré :

• Capturer une baseline : lsblk -f, blkid, efibootmgr -v (UEFI), plus /etc/fstab et /etc/crypttab.
• Décider et documenter : UEFI ou BIOS hérité. Appliquez cette décision dans les réglages firmware de la flotte.
• Uniformiser la disposition de /boot et de l’ESP. La cohérence est une caractéristique de disponibilité.
• Effectuer des contrôles réguliers de santé des disques et alerter sur les erreurs d’E/S. Les chargeurs d’amorçage échouent bruyamment, les disques échouent créativement.

Si vous traitez le démarrage comme une plomberie de production — traçable, reproductible et pas fondée sur le folklore — vous verrez rarement grub rescue>.
Et quand cela arrivera, vous le réparerez avec un air impassible.