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 :
- La réparation réussie. Élimination de l’inutile.
- La réparation échouée et Ubuntu réparé via supergrub2disk.
- 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).
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.
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 :
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 :
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 :
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:
On 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à :
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.
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 :
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.