GRUB2 & UEFI — pwnewi study notes

01 — niveau fondamentaux

UEFI / BIOS

Q01 Quelle est la différence fondamentale entre le BIOS legacy et l'UEFI ? ▶

analogie Le BIOS legacy = réceptionniste des années 80 avec un carnet papier (MBR, 512 octets). L'UEFI = réceptionniste moderne avec une tablette connectée (partition ESP, fichiers .efi). Même mission, conception totalement différente.

BIOS Legacy

Firmware 16 bits, interface texte, conçu dans les années 1980
Cherche un bootloader dans le MBR — les 512 premiers octets du disque
Limite de 2 To par disque (MBR) et 4 partitions primaires maximum
Démarre en mode réel 16 bits — lent avant de passer en 32 bits

UEFI

Firmware 32/64 bits avec interface graphique, souris, réseau
Cherche un fichier .efi dans la partition ESP (EFI System Partition)
Supporte GPT → disques > 2 To, jusqu'à 128 partitions
Boot direct en 64 bits → démarrage plus rapide
Intègre Secure Boot — vérification des signatures numériques
Gestionnaire de boot intégré, manipulable via efibootmgr

# vérifier si le système a booté en UEFI

[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS legacy"

Q02 C'est quoi une partition GPT ? Pourquoi est-elle nécessaire avec UEFI ? ▶

GPT (GUID Partition Table) est le schéma de partitionnement moderne qui remplace le MBR.

MBR — ancien

512 octets · 4 partitions primaires · limite 2 To · pas de redondance · pas de CRC

GPT — moderne

128 partitions · disques > 2 To · table dupliquée en fin de disque · CRC32 pour intégrité

GPT est nécessaire avec UEFI car le firmware UEFI s'attend à trouver une partition de type ESP (code EF00) qui ne peut exister que dans un schéma GPT. Sans GPT → pas d'ESP → l'UEFI ne sait pas où charger le bootloader.

# vérifier le type de table de partitions

sudo fdisk -l /dev/sda | grep "Disklabel"

# ou avec gdisk (plus détaillé)

sudo gdisk -l /dev/sda

# lister toutes les partitions avec leur type

sudo parted /dev/sda print

Q03 À quoi sert la partition EFI (ESP) ? Pourquoi est-elle formatée en FAT32 ? ▶

L'ESP (EFI System Partition) est le point de départ universel du démarrage UEFI. Elle contient tous les chargeurs de boot installés sur la machine — Linux, Windows, etc.

# structure typique de l'ESP

/boot/efi/EFI/

├── ubuntu/

│ ├── grubx64.efi ← chargeur GRUB2

│ ├── shimx64.efi ← shim pour Secure Boot

│ └── grub.cfg ← config minimale (pointe vers /boot/grub/)

├── Microsoft/

│ └── Boot/bootmgfw.efi ← chargeur Windows

└── BOOT/bootx64.efi ← fallback universel

Pourquoi FAT32 ?

Le firmware UEFI doit lire l'ESP avant tout OS. Il a besoin d'un système de fichiers qu'il comprend nativement. La spécification UEFI impose FAT32 car c'est un format simple, universel, lisible par n'importe quel firmware. Ext4, NTFS ou Btrfs seraient invisibles pour le firmware.

# identifier et monter l'ESP

sudo blkid | grep -i vfat

sudo mount /dev/sda1 /mnt/boot/efi

Q04 Comment vérifier si mon système a booté en mode UEFI ou BIOS ? ▶

# méthode 1 — /sys/firmware/efi (n'existe qu'en UEFI)

[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS legacy"

# méthode 2 — lister les variables EFI

ls /sys/firmware/efi/efivars/

# méthode 3 — efibootmgr (échoue si BIOS mode)

sudo efibootmgr -v

# méthode 4 — journal de démarrage

dmesg | grep -i efi

règle rapide Si /sys/firmware/efi existe → UEFI. S'il est absent → BIOS legacy. C'est la méthode la plus fiable.

Q05 C'est quoi le Secure Boot ? Pourquoi ça pose problème avec Linux ? ▶

Secure Boot est une fonctionnalité UEFI qui vérifie la signature cryptographique de chaque composant chargé au démarrage. Seuls les binaires .efi signés avec des clés reconnues par le firmware sont autorisés.

Le problème avec Linux

Par défaut, les firmwares UEFI font confiance aux clés Microsoft. Le noyau Linux et GRUB2 ne sont pas signés par Microsoft → refus de démarrage si Secure Boot est activé.

La solution — shimx64.efi

1

Firmware UEFI charge shimx64.efi — signé par Microsoft ✓

2

Shim vérifie grubx64.efi — signé Canonical via MOK ✓

3

GRUB2 vérifie le noyau Linux — signé Canonical ✓

4

Noyau démarre → système opérationnel

# vérifier l'état du Secure Boot

mokutil --sb-state

# lister les clés MOK (Machine Owner Key) enregistrées

mokutil --list-enrolled

contournement Désactiver le Secure Boot dans le firmware UEFI est la solution la plus simple pour les distributions non officiellement supportées ou les kernels custom.

02 — niveau architecture

Architecture de GRUB2

Q06 Arborescence de GRUB2 : /etc/default/grub, /etc/grub.d/, /boot/grub/grub.cfg ▶

analogie C'est comme compiler un binaire : les sources (/etc/default/grub + scripts /etc/grub.d/) sont compilées en un fichier final (/boot/grub/grub.cfg). On ne modifie jamais le binaire final directement.

/etc/default/grub

Variables globales : timeout, entrée par défaut, paramètres noyau. C'est ici qu'on édite les options GRUB.

/etc/grub.d/

Scripts exécutables numérotés qui génèrent des sections de grub.cfg. Exécutés dans l'ordre : 00_header, 10_linux, 30_os-prober...

/boot/grub/grub.cfg

Fichier final généré automatiquement. NE JAMAIS ÉDITER MANUELLEMENT. Résultat de update-grub.

/boot/efi/EFI/ubuntu/grub.cfg

Mini-fichier dans l'ESP. Dit juste à GRUB de chercher le vrai grub.cfg dans /boot/grub/. Lu en premier par GRUB.

# explorer l'arborescence GRUB2

ls /etc/grub.d/

# voir la config principale

cat /etc/default/grub

# voir le début du grub.cfg généré

head -50 /boot/grub/grub.cfg

# voir le mini-fichier dans l'ESP

sudo cat /boot/efi/EFI/ubuntu/grub.cfg

Q07 Quelle est la différence entre update-grub et grub-mkconfig ? ▶

update-grub est un simple wrapper shell qui appelle grub-mkconfig avec les bons arguments. Ils font exactement la même chose.

# ces deux commandes sont équivalentes

sudo update-grub

sudo grub-mkconfig -o /boot/grub/grub.cfg

# voir ce que fait update-grub

cat /usr/sbin/update-grub

Les deux commandes : exécutent tous les scripts /etc/grub.d/* dans l'ordre numérique, lisent /etc/default/grub, et génèrent le nouveau /boot/grub/grub.cfg.

portabilité update-grub est propre à Ubuntu/Debian. Sur Fedora/RHEL/Arch, utiliser directement grub-mkconfig -o /boot/grub/grub.cfg ou grub2-mkconfig.

Q08 Comment GRUB2 trouve-t-il le noyau Linux et l'initramfs ? ▶

Séquence complète de démarrage UEFI + GRUB2

1

Firmware UEFI charge shimx64.efi ou grubx64.efi depuis l'ESP

2

GRUB2 lit le mini-config dans l'ESP qui contient un search pour trouver la partition /boot

3

GRUB2 monte la partition /boot et lit /boot/grub/grub.cfg

4

Le menu GRUB s'affiche avec les entrées générées par le script 10_linux

5

Après sélection, GRUB charge /boot/vmlinuz-x.x.x et /boot/initrd.img-x.x.x en RAM

6

GRUB passe le contrôle au noyau Linux avec tous les paramètres configurés

# voir les noyaux disponibles dans /boot

ls /boot/vmlinuz-* /boot/initrd.img-*

# voir les entrées menuentry dans grub.cfg

grep "menuentry" /boot/grub/grub.cfg

Q09 C'est quoi un fichier .efi ? Où est stocké grubx64.efi ? ▶

Un fichier .efi est un exécutable au format PE32+ (Portable Executable) — le même format que les .exe Windows — compilé pour l'environnement UEFI. Le firmware UEFI sait les lire et les exécuter nativement, avant même qu'un OS soit chargé.

# emplacements des fichiers .efi principaux

/boot/efi/EFI/ubuntu/grubx64.efi ← GRUB2 pour x86_64

/boot/efi/EFI/ubuntu/shimx64.efi ← Shim Secure Boot

/boot/efi/EFI/BOOT/bootx64.efi ← fallback universel

# vérifier présence et taille

ls -lh /boot/efi/EFI/ubuntu/

# confirmer que c'est bien un binaire EFI

file /boot/efi/EFI/ubuntu/grubx64.efi

# grubx64.efi: PE32+ executable (EFI application) x86-64

architecture Le "x64" signifie architecture x86_64 (AMD64). Sur ARM, ce serait grubaa64.efi.

03 — niveau configuration

Configuration pratique

Q10 Comment changer le timeout de GRUB2 ? Comment changer l'entrée par défaut ? ▶

# éditer /etc/default/grub

sudo nano /etc/default/grub

# ── timeout ──

GRUB_TIMEOUT=5 # délai en secondes

GRUB_TIMEOUT=0 # boot immédiat

GRUB_TIMEOUT=-1 # attente infinie

# ── entrée par défaut ──

GRUB_DEFAULT=0 # première entrée (index)

GRUB_DEFAULT="Ubuntu, with Linux 6.5.0" # par nom exact

GRUB_DEFAULT=saved # mémoriser le dernier choix

GRUB_SAVEDEFAULT=true # (requis avec saved)

# toujours appliquer les changements

sudo update-grub

attention Ne jamais éditer /boot/grub/grub.cfg directement — vos changements seront écrasés au prochain update-grub.

Q11 Comment ajouter des paramètres au noyau Linux via GRUB2 (ex: nomodeset) ? ▶

# dans /etc/default/grub, modifier GRUB_CMDLINE_LINUX_DEFAULT

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" # défaut

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset" # GPU problématique

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem=4G" # limiter RAM

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off" # désactiver ACPI

# différence entre les deux variables

GRUB_CMDLINE_LINUX_DEFAULT # boot normal seulement

GRUB_CMDLINE_LINUX # TOUS les boots (y compris recovery)

# appliquer

sudo update-grub

astuce Pour tester un paramètre sans modifier les fichiers : appuyer sur E dans le menu GRUB pour éditer l'entrée temporairement. Perdu au redémarrage suivant.

Q12 Comment réparer GRUB2 depuis un live CD/USB ? ▶

Méthode universelle — chroot

# 1. démarrer depuis le live USB puis ouvrir un terminal

# 2. identifier vos partitions

lsblk -f

# 3. monter la partition racine Linux (ex: sda2)

sudo mount /dev/sda2 /mnt

# 4. monter l'ESP (ex: sda1)

sudo mount /dev/sda1 /mnt/boot/efi

# 5. bind-monter les pseudo-systèmes de fichiers

for i in /dev /dev/pts /proc /sys /run; do

sudo mount --bind $i /mnt$i

done

# 6. entrer dans le chroot

sudo chroot /mnt

# 7. dans le chroot — réinstaller GRUB (UEFI)

grub-install --target=x86_64-efi --efi-directory=/boot/efi \

--bootloader-id=ubuntu --recheck

# 8. régénérer la configuration

update-grub

# 9. quitter et redémarrer

exit

sudo reboot

Q13 Comment désactiver le menu GRUB2 pour un boot plus rapide ? ▶

# dans /etc/default/grub

GRUB_TIMEOUT=0 # délai zéro

GRUB_TIMEOUT_STYLE=hidden # cacher le menu

# appliquer

sudo update-grub

accès d'urgence Même avec TIMEOUT=0, maintenir Shift (BIOS) ou Échap (UEFI) au démarrage force l'affichage du menu.

production Garder un timeout d'au moins 1-2 secondes sur un système dual-boot ou de production pour garder accès au menu en cas de problème.

04 — niveau dépannage avancé

Dépannage avancé

Q14 Mon système affiche grub rescue> — que faire ? Quelles commandes utiliser ? ▶

grub rescue> apparaît quand GRUB ne trouve pas ses modules ou sa configuration. Version minimale de GRUB sans modules chargés.

# 1. identifier les disques disponibles

grub rescue> ls

(hd0) (hd0,gpt1) (hd0,gpt2)

# 2. chercher /boot/grub sur chaque partition

grub rescue> ls (hd0,gpt2)/boot/grub/

# 3. si trouvé — définir la partition racine

grub rescue> set root=(hd0,gpt2)

grub rescue> set prefix=(hd0,gpt2)/boot/grub

# 4. charger le module normal

grub rescue> insmod normal

# 5. lancer GRUB normalement

grub rescue> normal

# 6. une fois dans le vrai GRUB ou après boot — réparer

sudo update-grub

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi

cas extrême Si ls ne montre aucune partition, le problème est matériel ou la table GPT est corrompue. Passer directement au live USB.

Q15 Après une mise à jour de Windows, GRUB2 a disparu. Comment le restaurer ? ▶

Windows (surtout les grosses mises à jour) réécrit l'entrée UEFI par défaut pour pointer vers son propre bootloader, ou écrase le fallback bootx64.efi.

# depuis un live USB — méthode chroot (voir Q12) puis dans le chroot :

grub-install --target=x86_64-efi --efi-directory=/boot/efi \

--bootloader-id=ubuntu

update-grub

exit

# vérifier que l'entrée Ubuntu est revenue

sudo efibootmgr -v

# mettre Ubuntu en tête de l'ordre de boot

sudo efibootmgr -o 0000,0001,0002

# vérifier que Windows est bien détecté par GRUB

sudo os-prober

sudo update-grub

Q16 Comment GRUB2 gère-t-il le dual-boot avec Windows ? ▶

GRUB2 utilise os-prober, un script qui scanne tous les disques pour détecter d'autres systèmes d'exploitation installés.

# activer la détection dans /etc/default/grub

GRUB_DISABLE_OS_PROBER=false

# lancer la détection manuellement

sudo os-prober

/dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

# régénérer avec les entrées Windows détectées

sudo update-grub

# entrée Windows générée dans grub.cfg :

menuentry "Windows Boot Manager (sur /dev/sda1)" {

insmod chain

chainloader /EFI/Microsoft/Boot/bootmgfw.efi

}

chainloading GRUB ne démarre pas Windows directement. Il charge le bootloader Windows (bootmgfw.efi) et lui passe le contrôle. Windows prend en charge le reste.

Q17 Comment fonctionne efibootmgr ? Comment l'utiliser pour réparer l'ordre de boot ? ▶

efibootmgr lit et modifie la NVRAM UEFI — les variables stockées dans le firmware qui définissent l'ordre et les entrées de boot.

# lister toutes les entrées avec détails

sudo efibootmgr -v

BootCurrent: 0000

BootOrder: 0000,0001,0002

Boot0000* ubuntu HD(1,GPT,...)/File(\EFI\ubuntu\shimx64.efi)

Boot0001* Windows HD(1,GPT,...)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

# changer l'ordre de boot

sudo efibootmgr -o 0000,0001 # Ubuntu en premier

# créer une nouvelle entrée

sudo efibootmgr --create --disk /dev/sda --part 1 \

--label "ubuntu" --loader '\EFI\ubuntu\shimx64.efi'

# supprimer une entrée

sudo efibootmgr -b 0000 -B

# activer / désactiver une entrée

sudo efibootmgr -b 0001 -a # activer

sudo efibootmgr -b 0001 -A # désactiver

Q18 C'est quoi shimx64.efi ? Quel est son rôle avec le Secure Boot ? ▶

Le shim est un minuscule programme intermédiaire signé par Microsoft. Il résout le problème de confiance entre le firmware UEFI (qui ne fait confiance qu'à Microsoft) et GRUB/Linux.

Chaîne de confiance complète

1

Firmware UEFI → vérifie shimx64.efi — signé Microsoft ✓

2

Shim → vérifie grubx64.efi — signé Canonical via MOK ✓

3

GRUB2 → vérifie le noyau Linux — signé Canonical ✓

4

Noyau démarre → système opérationnel

# vérifier la présence du shim

ls -la /boot/efi/EFI/ubuntu/shimx64.efi

# le shim est aussi le fallback BOOT/ sur Ubuntu

ls -la /boot/efi/EFI/BOOT/

# gérer les clés MOK (Machine Owner Keys)

mokutil --list-enrolled # clés enregistrées

mokutil --import ma-cle.der # ajouter une clé

sans shim Sans shim, il faudrait soit désactiver Secure Boot, soit enregistrer manuellement la clé Canonical dans le firmware UEFI via l'interface graphique du firmware.

05 — lab pratique

De la panne à la réparation

prérequis Une VM Linux avec UEFI activé (VirtualBox ou QEMU). Créer un snapshot "Before GRUB lab" avant de commencer.

Étape 1 — Préparation

5 min

# vérifier le mode UEFI

[ -d /sys/firmware/efi ] && echo "OK: UEFI mode" || echo "ERREUR: BIOS mode"

# explorer l'état sain avant de casser quoi que ce soit

sudo efibootmgr -v

sudo ls -l /boot/efi/EFI/

ls /boot/grub/grub.cfg

[ -f /boot/efi/EFI/ubuntu/grubx64.efi ] && echo "chargeur EFI OK"

Scénario A — grub.cfg disparu

Facile

⚠ correction vs document original Le document original indiquait grub rescue>, (hd0,gpt2)/boot/grub comme prefix, et la syntaxe insmod normal && normal. Les trois sont incorrects sur cette config. Voir les notes de session ci-dessous.

# ── CASSER ──

sudo mv /boot/grub/grub.cfg /boot/grub/grub.cfg.bak

sudo reboot

# résultat réel : invite grub> (pas grub rescue>) — modules chargés, grub.cfg introuvable

# ── DIAGNOSTIC — identifier les partitions ──

grub> ls

# (proc) (memdisk) (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0) (lvm/ubuntu--vg-ubuntu--lv)

grub> ls (hd0,gpt2)/grub

# unicode.pf2 x86_64-efi/ locale/ fonts/ grub.cfg.bak grubenv

# sda2 EST /boot — donc le prefix est (hd0,gpt2)/grub, pas /boot/grub

# ── RÉPARER depuis grub> — commandes séparées (pas &&) ──

grub> set root=(hd0,gpt2)

grub> set prefix=(hd0,gpt2)/grub

grub> insmod normal

grub> normal

# normal sans grub.cfg = silencieux, rien ne se passe → boot manuel nécessaire

# ── BOOT MANUEL (grub.cfg absent = normal ne boot pas) ──

grub> linux (hd0,gpt2)/vmlinuz root=/dev/mapper/ubuntu--vg-ubuntu--lv

grub> initrd (hd0,gpt2)/initrd.img

grub> boot

# résultat : shell initramfs (le noyau démarre mais LVM pas encore monté)

# ── DEPUIS LE SHELL INITRAMFS ──

mount /dev/mapper/ubuntu--vg-ubuntu--lv /root

# /boot est une partition séparée (sda2) — pas dans le LVM

mount /dev/sda2 /root/boot

mv /root/boot/grub/grub.cfg.bak /root/boot/grub/grub.cfg

reboot -f

# machine reboot normalement — GRUB trouve grub.cfg, menu s'affiche

# ── ALTERNATIVE : régénérer proprement depuis le système démarré ──

sudo update-grub

💡 leçon clé grub.cfg est un script — il contient exactement les commandes tapées manuellement (set root, linux, initrd). Le fichier automatise ce que vous avez fait à la main. Supprimer grub.cfg = devoir rejouer ces commandes manuellement à chaque boot.

🔴 angle sécurité Un bootkit qui corrompt grub.cfg peut remplacer la ligne linux /vmlinuz par un noyau malveillant. Le chemin de récupération ci-dessus est exactement ce qu'un attaquant exploite — root sur /boot suffit pour rediriger l'exécution avant le chargement de l'OS. TPM + Secure Boot mesurent cette partition pour détecter la modification.

Scénario B — Chargeur EFI corrompu

Intermédiaire

# ── CASSER ──

sudo mv /boot/efi/EFI/ubuntu/grubx64.efi \

/boot/efi/EFI/ubuntu/grubx64.efi.bak

sudo reboot

# résultat : firmware ne trouve pas Linux

# ── RÉPARER depuis live USB (dans le chroot) ──

grub-install --target=x86_64-efi \

--efi-directory=/boot/efi \

--bootloader-id=ubuntu --recheck

update-grub

Scénario C — Entrée UEFI supprimée

Avancé

# ── CASSER — identifier l'entrée Linux d'abord ──

sudo efibootmgr

# repérer le numéro (ex: Boot0000) puis supprimer

sudo efibootmgr -b 0000 -B

sudo reboot

# résultat : Linux n'apparaît plus dans le menu UEFI

# ── RÉPARER depuis live USB (dans le chroot) ──

grub-install --target=x86_64-efi \

--efi-directory=/boot/efi \

--bootloader-id=ubuntu

update-grub

exit

# vérifier que l'entrée est recréée

sudo efibootmgr -v

Étape 4 — Vérification finale

5 min

[ -f /boot/grub/grub.cfg ] && echo "✓ grub.cfg présent"

[ -f /boot/efi/EFI/ubuntu/grubx64.efi ] && echo "✓ chargeur EFI présent"

sudo efibootmgr | grep -i ubuntu && echo "✓ entrée UEFI présente"

grep "menuentry" /boot/grub/grub.cfg | head -5

sudo cat /boot/efi/EFI/ubuntu/grub.cfg

06 — auto-évaluation

Répondez sans regarder

A01 Quelle est la différence entre grub.cfg dans /boot/grub/ et dans /boot/efi/EFI/ubuntu/ ? ▶

/boot/efi/EFI/ubuntu/grub.cfg est un mini-fichier dans l'ESP (FAT32). Il contient seulement un search pour trouver la partition /boot et un configfile qui pointe vers le vrai fichier. Lu en premier par GRUB, avant de monter le système de fichiers Linux.

/boot/grub/grub.cfg est le vrai fichier de configuration, généré par update-grub, avec toutes les entrées menuentry, les paramètres noyau, et la configuration complète.

A02 Quelle commande : régénère la config ? Réinstalle le chargeur EFI ? Modifie l'ordre de boot ? ▶

# régénérer la configuration de GRUB

sudo update-grub

# (équivalent sur toutes les distros)

sudo grub-mkconfig -o /boot/grub/grub.cfg

# réinstaller le chargeur dans la partition EFI

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

# modifier l'ordre de boot UEFI

sudo efibootmgr -o 0000,0001,0002

A03 Que faire si vous voyez grub rescue> au démarrage ? ▶

grub rescue> ls

grub rescue> ls (hd0,gpt2)/boot/grub/

grub rescue> set root=(hd0,gpt2)

grub rescue> set prefix=(hd0,gpt2)/boot/grub

grub rescue> insmod normal

grub rescue> normal

# puis réparer depuis le système démarré

sudo update-grub && sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi

A04 Windows a supprimé l'entrée Linux dans l'UEFI. Procédure ? ▶

Live USB → chroot → grub-install → update-grub → efibootmgr -v pour vérifier que l'entrée est recréée → efibootmgr -o pour mettre Linux en tête.

# dans le chroot

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

update-grub

exit

sudo efibootmgr -v

sudo os-prober && sudo update-grub

A05 Le noyau Linux a été mis à jour mais GRUB ne le voit pas. Que faire ? ▶

Simplement lancer sudo update-grub. Le script 10_linux va scanner tous les noyaux présents dans /boot/ et les ajouter automatiquement au grub.cfg.

# vérifier que le noyau est bien dans /boot

ls /boot/vmlinuz-*

# régénérer

sudo update-grub

# vérifier qu'il apparaît maintenant

grep "menuentry" /boot/grub/grub.cfg