Nettoyer les traces de réparation faite avec Boot-repair en UEFI

Lors d’un problème au démarrage, on a souvent tendance à se lancer vers la réparation automatique proposée par Boot-Repair. Personnellement, je déconseille ce choix, car celle-ci peut fonctionner ou ne pas fonctionner, et c’est assez fréquent… Quoi qu’il en soit, elle laisse toujours des traces et elle fait des opérations inutiles. Comment les supprimer ?

On va imaginer trois scénarios :

  1. La réparation réussie. Élimination de l’inutile.
  2. La réparation échouée et Ubuntu réparé via supergrub2disk.
  3. La réparation échouée, partition efi formatée, et réparée par console M$ et live-cd.

I) Nettoyage d’une réparation réussie.

Après notre réparation qui a fonctionné, puisqu’on a un menu Grub, Boot-Repair a ajouté des entrées supplémentaires, pas forcément utiles, et qui sont parfois inopérantes (ici, on a trois entrées ajoutées, mais parfois, ça peut dépasser la dizaine).

menu-grub

Nous allons donc démarrer sur notre Linux Mint qui, grâce à B-R, fonctionne parfaitement.

Un boot-info va nous renseigner sur les détails de la réparation : boot-info

1. Constats sur la réparation faite par BR.

  • Boot-repair a ajouté des fichiers backup à la partition efi (et donc renommé d’autres fichiers):
sda2: File system:       vfat
    Operating System:  
    Boot files:        /EFI/Boot/bkpbootx64.efi /EFI/Boot/bootx64.efi 
                       /EFI/ubuntu/MokManager.efi /EFI/ubuntu/grubx64.efi 
                       /EFI/ubuntu/shimx64.efi 
                       /EFI/Microsoft/Boot/bootmgfw.efi 
                       /EFI/Microsoft/Boot/bootmgr.efi 
                       /EFI/Microsoft/Boot/memtest.efi

On le voit nettement ici :

Save and rename /boot/efi/EFI/Boot/bootx64.efi (/boot/efi/EFI/Boot/bkpbootx64.efi)
cp /boot/efi/EFI/ubuntu/shimx64.efi /boot/efi/EFI/Boot/bootx64.efi
Adding custom /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
Adding custom /boot/efi/EFI/Boot/bkpbootx64.efi
sda2/bkpbootx64.efi already added
Adding custom /boot/efi/EFI/ubuntu/MokManager.efi
sda2/bootmgfw.efi already added
  •   Il a ajouté un fichier 25_custom dans le dossier /etc/grub.d
### BEGIN /etc/grub.d/25_custom ###

menuentry "Windows UEFI bootmgfw.efi" {
search --fs-uuid --no-floppy --set=root F24D-B9B7
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
}

menuentry "Windows Boot UEFI loader" {
search --fs-uuid --no-floppy --set=root F24D-B9B7
chainloader (${root})/EFI/Boot/bkpbootx64.efi
}

menuentry "EFI/ubuntu/MokManager.efi" {
search --fs-uuid --no-floppy --set=root F24D-B9B7
chainloader (${root})/EFI/ubuntu/MokManager.efi
}
### END /etc/grub.d/25_custom ###
  •  Il a réinstallé grub-efi-amd64-signed
uname -r
Kernel: 3.13.0-24-generic

Reinstall the grub-efi-amd64-signed of sda6
Installing for x86_64-efi platform.
Installation finished. No error reported.
grub-install --uefi-secure-boot : exit code of grub-install :0

La réinstallation de Grub ne posant pas de problème, on va se concentrer sur les deux premiers points.

 2. Les vérifications et réparations sur la partition efi.

On va comparer les identificateurs des fichiers présents sur la partition efi grâce à la commande md5sum :

test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/Boot/bkpbootx64.efi
87b6d22295a16073d8d456fc574441a8  /boot/efi/EFI/Boot/bkpbootx64.efi
test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
87b6d22295a16073d8d456fc574441a8  /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/ubuntu/MokManager.efi
ba8a7979ac57f1c0c307ef94d1020eb8  /boot/efi/EFI/ubuntu/MokManager.efi
test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/ubuntu/grubx64.efi
0b48de05c935c48c9e4a94fa820c32ba  /boot/efi/EFI/ubuntu/grubx64.efi
test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/Boot/bootx64.efi
ded965934506efb38a6dcb9ac5b2b79e  /boot/efi/EFI/Boot/bootx64.efi
test@test-virtual-machine ~ $  md5sum  /boot/efi/EFI/Ubuntu/shimx64.efi
ded965934506efb38a6dcb9ac5b2b79e  /boot/efi/EFI/Ubuntu/shimx64.efi

On constate que deux fichiers ont été copiés et placés dans le dossier /efi/boot. Cette duplication étant inutile, on va donc les supprimer.

test@test-virtual-machine ~ $ sudo rm -rf /boot/efi/EFI/Boot
[sudo] password for test:
test@test-virtual-machine ~ $ ls /boot/efi/EFI
Microsoft  ubuntu
test@test-virtual-machine ~ $

Les deux fichiers ont bien été supprimés, ainsi que le dossier /efi/boot qui est complètement inutile.

Remarque : les premiers bios uefi tendent à booter sur /boot/efi/EFI/Boot/bootx64.efi. Dans ce cas, il sera plus prudent de renommer le fichier bootx64.efi comme à l’origine. Donc :

test@test-virtual-machine ~ $ cp /boot/efi/EFI/Boot/bkpbootx64.efi /boot/efi/EFI/Boot/bootx64.efi
[sudo] password for test:
est@test-virtual-machine ~ $ sudo rm -f /boot/efi/EFI/Boot/bkpbootx64.efi
test@test-virtual-machine ~ $

3. Les vérifications et réparations sur le fichier 25_custom

On vérifie sa présence dans le dossier /etc/grub.d. Le plus simple est de le désactiver avec la commande chmod -x.

test@test-virtual-machine ~ $ ls /etc/grub.d
00_header        06_mint_theme  10_lupin      20_memtest86+  30_os-prober      40_custom  README
05_debian_theme  10_linux       20_linux_xen  25_custom      30_uefi-firmware  41_custom
test@test-virtual-machine ~ $ sudo chmod -x /etc/grub.d/25_custom

On pourrait s’arrêter ici, on a rendu le fichier inactif. Mais on peut choisir de carrément le supprimer.

test@test-virtual-machine ~ $ sudo rm -f /etc/grub.d/25_custom
test@test-virtual-machine ~ $ ls /etc/grub.d
00_header        06_mint_theme  10_lupin      20_memtest86+  30_uefi-firmware  41_custom
05_debian_theme  10_linux       20_linux_xen  30_os-prober   40_custom         README
test@test-virtual-machine ~ $

Le fichier a bel et bien disparu. Il ne reste plus qu’à mettre grub à jour pour voir si les choses sont correctes :

test@test-virtual-machine ~ $ sudo update-grub
Création du fichier de configuration GRUB…
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
  No volume groups found
Windows Boot Manager trouvé sur /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
fait
test@test-virtual-machine ~ $

A priori, les entrées pour Linux et Windows sont trouvées, il ne reste qu’à redémarrer pour s’assurer que c’est bon.

menu-grub2

On peut vérifier le résultat avec un nouveau boot-info. Il reste une dernière trace de boot-repair, un dossier caché « boot-sav » qui n’apparaissait pas avec la commande ls:

sda2: _____________________________________________
                       /boot-sav/log/2016-10-12__11h34boot-repair00/sda2/bootx
                       64.efi

Nous allons simplement la supprimer et vérifier sa disparition avec la commande ls -a:

test@test-virtual-machine ~ $ sudo rm -rf /boot/efi/boot-sav
test@test-virtual-machine ~ $ ls -a /boot/efi
.  ..  EFI

On n’a plus de trace de l’intervention de Boot-Repair.

II). Nettoyage d’une réparation ratée

1. Réparation « soft », depuis Linux installé lancé par Supergrub2disk

Envisageons une réparation échouée (sous VMware, c’est plutôt rare, donc j’ai trafiqué le démarrage pour reproduire une situation qu’on rencontre parfois). Seul Windows démarre, ce qui est un cas assez fréquent, même après une réparation faite avec boot-repair

Le CD bootable super grub2disk (un outil bien utile) nous permet de faire démarrer notre Mint HS. Grâce à lui, on va pouvoir faire un boot-info des résultats de la réparation.

L’échec (supposé) apparaît ici :

=================== efibootmgr -v
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0002,0001,0003,0004,0000
Boot0000* EFI Internal Shell (Unsupported option)	MM(b,3efcb000,3f355fff)
Boot0001* EFI VMware Virtual SCSI Hard Drive (0.0)	ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0)
Boot0002* Windows Boot Manager	HD(2,96800,31800,c9a0dbcc-884b-4ab4-bd18-6fbb096f1091)File(EFIMicrosoftBootbootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...b................
Boot0003* EFI VMware Virtual SATA CDROM Drive (1.0)	ACPI(a0341d0,0)PCI(11,0)PCI(4,0)03120a00010000000000
Boot0004* EFI Network	ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(000c29d625c6,0)

L’entrée Ubuntu est décrétée absente. La réparation n’a pas résolu le problème. Pourtant, boot-repair a bien ajouté son fichier 25_custom et renommé shimx64.efi  :

### BEGIN /etc/grub.d/25_custom ###
menuentry "Windows UEFI bootmgfw.efi" {search --fs-uuid --no-floppy --set=root F24D-B9B7 chainloader (${root})/EFI/Microsoft Boot/bootmgfw.efi }
menuentry "EFI/ubuntu/MokManager.efi" {search --fs-uuid --no-floppy --set=root F24D-B9B7 chainloader (${root})/EFI/ubuntu/MokManager.efi}
### END /etc/grub.d/25_custom ###

Boot files:        /EFI/Boot/bootx64.efi

On va donc utiliser la même méthode que précédemment pour supprimer ces ajouts inutiles :

test@test-virtual-machine ~ $ sudo rm -rf /boot/efi/EFI/Boot
[sudo] password for test: 
test@test-virtual-machine ~ $ ls -a /boot/efi
.  ..  boot-sav  EFI
test@test-virtual-machine ~ $ sudo rm -rf /boot/efi/boot-sav
test@test-virtual-machine ~ $ sudo chmod -x /etc/grub.d/25_custom
test@test-virtual-machine ~ $ sudo rm -f /etc/grub.d/25_custom
test@test-virtual-machine ~ $

On a supprimé le dossier boot, puis boot-sav, et enfin 25-custom. On va tenter de réinstaller grub. On commence par désinstaller les versions en place qu’on suppose mauvaises:

test@test-virtual-machine ~ $ sudo apt-get autoremove grub-efi-amd64-signed 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  grub-efi-amd64-signed
0 mis à jour, 0 nouvellement installés, 1 à enlever et 849 non mis à jour.
Après cette opération, 2 997 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 151916 fichiers et répertoires déjà installés.)
Suppression de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
test@test-virtual-machine ~ $ sudo apt-get autoremove shim-signed 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  libefivar0 mokutil shim shim-signed
0 mis à jour, 0 nouvellement installés, 4 à enlever et 849 non mis à jour.
Après cette opération, 4 270 ko d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 151908 fichiers et répertoires déjà installés.)
Suppression de shim-signed (1.18~14.04.1+0.8-0ubuntu2) ...
Suppression de mokutil (0.3.0-0ubuntu3~14.04.1) ...
Suppression de libefivar0:amd64 (0.21-1~14.04.2) ...
Suppression de shim (0.8-0ubuntu2) ...
Traitement déclenché pour  man-db (2.6.7.1-1) ...
Traitement déclenché pour  libc-bin (2.19-0ubuntu6) ...

Ensuite, on les réinstalle proprement :

test@test-virtual-machine ~ $ sudo apt-get install -y grub-efi-amd64-signed shim-signed 
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés : 
  libefivar0 mokutil shim
Paquets recommandés :
  secureboot-db
Les NOUVEAUX paquets suivants seront installés :
  grub-efi-amd64-signed libefivar0 mokutil shim shim-signed
0 mis à jour, 5 nouvellement installés, 0 à enlever et 849 non mis à jour.
Il est nécessaire de prendre 0 o/1 066 ko dans les archives.
Après cette opération, 7 267 ko d'espace disque supplémentaires seront utilisés.
Préconfiguration des paquets...
Sélection du paquet libefivar0:amd64 précédemment désélectionné.
(Lecture de la base de données... 151882 fichiers et répertoires déjà installés.)
Préparation du décompactage de .../libefivar0_0.21-1~14.04.2_amd64.deb ...
Décompactage de libefivar0:amd64 (0.21-1~14.04.2) ...
Sélection du paquet grub-efi-amd64-signed précédemment désélectionné.
Préparation du décompactage de .../grub-efi-amd64-signed_1.34.14+2.02~beta2-9ubuntu1.12_amd64.deb ...
Décompactage de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
Sélection du paquet mokutil précédemment désélectionné.
Préparation du décompactage de .../mokutil_0.3.0-0ubuntu3~14.04.1_amd64.deb ...
Décompactage de mokutil (0.3.0-0ubuntu3~14.04.1) ...
Sélection du paquet shim précédemment désélectionné.
Préparation du décompactage de .../shim_0.8-0ubuntu2_amd64.deb ...
Décompactage de shim (0.8-0ubuntu2) ...
Sélection du paquet shim-signed précédemment désélectionné.
Préparation du décompactage de .../shim-signed_1.18~14.04.1+0.8-0ubuntu2_amd64.deb ...
Décompactage de shim-signed (1.18~14.04.1+0.8-0ubuntu2) ...
Traitement déclenché pour  man-db (2.6.7.1-1) ...
Paramétrage de libefivar0:amd64 (0.21-1~14.04.2) ...
Paramétrage de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
Installing for x86_64-efi platform.
Installation terminée, sans erreur.
Paramétrage de mokutil (0.3.0-0ubuntu3~14.04.1) ...
Paramétrage de shim (0.8-0ubuntu2) ...
Paramétrage de shim-signed (1.18~14.04.1+0.8-0ubuntu2) ...
Installing for x86_64-efi platform.
Installation terminée, sans erreur.
Traitement déclenché pour  libc-bin (2.19-0ubuntu6) ...
test@test-virtual-machine ~ $

Il ne reste plus qu’à faire une mise à jour de Grub pour espérer que notre Mint accepte de se lancer :

test@test-virtual-machine ~ $ sudo update-grub
Création du fichier de configuration GRUB…
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
  No volume groups found
Windows Boot Manager trouvé sur /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
fait
test@test-virtual-machine ~ $

Voyons maintenant si les entrées ont été ajoutées :

test@test-virtual-machine ~ $ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0005,0002,0001,0003,0004,0000
Boot0000* EFI Internal Shell (Unsupported option)	MM(b,3efcb000,3f355fff)
Boot0001* EFI VMware Virtual SCSI Hard Drive (0.0)	ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0)
Boot0002* Windows Boot Manager	HD(2,96800,31800,c9a0dbcc-884b-4ab4-bd18-6fbb096f1091)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...b................
Boot0003* EFI VMware Virtual SATA CDROM Drive (1.0)	ACPI(a0341d0,0)PCI(11,0)PCI(4,0)03120a00010000000000
Boot0004* EFI Network	ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(000c29d625c6,0)
Boot0005* ubuntu	HD(2,96800,31800,c9a0dbcc-884b-4ab4-bd18-6fbb096f1091)File(\EFI\ubuntu\shimx64.efi)

Mon PC bien nettoyé devrait booter sur la version signée de grub. Aucun problème :
menu-grub2

2. Réparation hard (formatage de la partition efi et live-cd).

Le cas le plus dramatique peut consister en un démarrage planté, tant pour Windows que pour Linux. On peut rencontrer le message cette situation bien connue :

rescue

On pourrait chercher à lancer Ubuntu avec des commandes (un tuto futur), mais là, on va carrément nettoyer la partition efi de A à Z.

 2.1 Première opération : le formatage.

On va démarrer sur le CD Dart, ou sur une clé d’installation et lancer le mode avancé de Windows pour obtenir une invite de commandes. On va formater la partition efi sans se poser de questions :

format

On a repéré la partition système, qui a été formatée en fat32. On aurait même pu la recréer pour être sûr qu’elle soit bien au format efi.

2.2. Réparation du démarrage de Windows.

On va déjà réparer le démarrage de Windows:

bcdbootOn identifie la lettre associée à la partition Windows grâce à la commande list vol et on répare le démarrage grâce à la commande bcdboot. Pas de problème, notre Windows est déjà réparé et il va se lancer : un dir depuis Windows sur la partition efi montre que les fichiers de démarrage sont bien là :

dir

 
2.3. Réparation du démarrage de Mint depuis le live-cd

Cette fois, on va éviter la facilité (de supergrub2disk) et réparer notre démarrage d’Ubuntu depuis un live-cd. Je me sers de Mint 17 puisque je l’ai sous la main. Nous allons devoir chrooter notre Linux pour pouvoir intervenir directement dessus. On passe d’abord le clavier en français par la commande setxkbmap fr

Puis, premier état des lieux sur les partitions (mon Linux s’appelle /dev/sda6 et mon efi /dev/sda2):

mint@mint ~ $ sudo parted -l
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sda: 46.2GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  316MB   315MB   ntfs            Basic data partition          hidden, diag
 2      316MB   419MB   104MB   fat32           EFI system partition          boot
 3      419MB   554MB   134MB                   Microsoft reserved partition  msftres
 4      554MB   28.2GB  27.6GB  ntfs            Basic data partition          msftdata
 5      28.2GB  33.9GB  5690MB  ntfs            Basic data partition          msftdata
 6      33.9GB  45.7GB  11.8GB  ext4
 7      45.7GB  46.2GB  499MB   linux-swap(v1)

Il ne reste qu’à monter tout ça pour chrooter et réinstaller grub. Détaillons un peu :

int@mint ~ $ sudo mount /dev/sda6 /mnt
mint@mint ~ $ sudo mount /dev/sda2 /mnt/boot/efi
mint@mint ~ $ for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
mint@mint ~ $ modprobe efivars
mint@mint ~ $ sudo chroot /mnt
mint / #

On a monté la partition Linux dans /mnt, puis la partition efi dans /mnt/boot/efi. On monte tous les outils nécessaires au chroot par une boucle, et on a activé le module efivars qui est indispensable en mode efi.  Passons à l’installation de grub. Un grub-install devrait suffire, mais on soigne le tout pour être sûr d’avoir les bons fichiers de grub.

mint / # grub-install grub-efi-amd64-signed
Installing for x86_64-efi platform.
Installation finished. No error reported.
mint / # grub-install shim-signed
Installing for x86_64-efi platform.
Installation finished. No error reported.

Il ne reste qu’à faire un update-grub pour réinstaller les fichiers.

mint / # update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
  No volume groups found
done

Grub est bien mis à jour, mais il ne voit pas Windows, et n’ajoute pas ses fichiers de démarrage… Ma Mint devrait malheureusement booter seule. On verra ça plus tard. Vérifions que les fichiers ont été correctement écrits sur la partition efi.

mint / # ls boot/efi/efi/ubuntu
grub.cfg  grubx64.efi  MokManager.efi  shimx64.efi

On quitte le chroot par CTRL D et on démonte tout ce qui a été monté.

mint / # exit
mint@mint ~ $ for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
mint@mint ~ $ sudo umount /mnt/boot/efi
mint@mint ~ $ sudo umount /mnt

Au redémarrage,  on constate qu’effectivement, seul Ubuntu se lance. Un message d’erreur s’est même ajouté, la partition efi n’étant pas correctement identifiée.

erreur_montage

C’est normal, car l’UUID de celle-ci a changé pour cause de formatage. On sélectionne S pour démarrer malgré l’erreur. Engageons les ultimes réparations: la commande blkid va nous donner la nouvelle uuid de la partition efi :

test@test-virtual-machine ~ $ blkid
/dev/sda1: UUID="5C48AE1048ADE94A" TYPE="ntfs" 
/dev/sda2: UUID="BA2F-12CE" TYPE="vfat" 
/dev/sda4: UUID="7E2C80D42C8088BB" TYPE="ntfs" 
/dev/sda5: LABEL="recup" UUID="B010EC0210EBCE02" TYPE="ntfs" 
/dev/sda6: UUID="0c23aeb1-bc05-496c-ac58-20786a9af8cf" TYPE="ext4" 
/dev/sda7: UUID="e5beef62-15b4-42ab-bc96-2e67b1b2c0de" TYPE="swap" 
/dev/sr0: LABEL="Linux Mint 17 Xfce 64-bit" TYPE="iso9660" 
test@test-virtual-machine ~ $

Nous allons modifier le fichier fstab avec l’éditeur de texte lancé par un sudo gedit /etc/fstab :

fstab

Nous constatons bel et bien une différence d’UUID. Il ne reste qu’à rectifier, enregistrer et redémarrer le pc. On peut retenter un sudo update-grub pour voir si, cette fois, notre Windows sera reconnu :

test@test-virtual-machine ~ $ sudo update-grub
[sudo] password for test: 
Création du fichier de configuration GRUB…
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
  No volume groups found
Windows Boot Manager trouvé sur /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
fait
test@test-virtual-machine ~ $

Aucun problème, il ne sera pas nécessaire d’ajouter l’entrée à la main dans 40_custom. Au redémarrage, nous constatons que tout fonctionne parfaitement. Boot-repair a été évité et notre démarrage est opérationnel.