Aujourd’hui un petit billet qui concerne le dépannage de mon notebook en dual boot Archlinux/Windows 8 qui n’a pas démarré sous Windows depuis quelques mois à cause d’un problème d’UEFI.
Attention!
Cet article a été écrit en 2015, la gestion de l'UEFI sous Linux a depuis changé et il faut désormais passer par systemd à la place de gummiboot. Merci d’en prendre compte lors de votre lecture.
Un formatage qui tourne plus ou moins mal
Lors d’une réinstallation de Arch sur ma machine, j’ai malencontreusement formaté la partition /boot qui accueille les fichiers pour le boot UEFI au format FAT32. Rien de bien grave car il suffit de réinstaller le paquet du noyau ainsi que Gummiboot (un bootloader UEFI) en utilisant un live-USB Arch pour pouvoir de nouveau booter sur la distribution installée sur le disque.
Sauf que dans le menu de Gummiboot n’apparait plus l’entrée pour démarrer sur Windows ! Rien de bien grave, Arch m’a suffit pendant les vacances mais la rentrée approchant il va falloir faire en sorte de pouvoir rebooter sous Windows pour les cours (et les jeux !).
Cause du problème
En appelant gummiboot dans un terminal root, celui-ci m’indique la liste des bootloaders référencés dans les variables UEFI :
[root@romain-msi ~]# gummiboot
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/91b92678-3b47-43b0-9b19-beac4afde64b
File: └─/EFI/gummiboot/gummibootx64.efi (gummiboot 48)
File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 224)
Boot Loader Entries in EFI Variables:
Title: Linux Boot Manager
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/91b92678-3b47-43b0-9b19-beac4afde64b
File: └─/EFI/gummiboot/gummibootx64.efi
Title: Windows Boot Manager
ID: 0x0003
Status: active, boot-order
Partition: /dev/disk/by-partuuid/91b92678-3b47-43b0-9b19-beac4afde64b
File: └─/EFI/Microsoft/Boot/bootmgfw.efi
Title: UEFI OS
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/91b92678-3b47-43b0-9b19-beac4afde64b
File: └─/EFI/BOOT/BOOTX64.EFI
Il y a donc bien un Windows Boot Manager qui traine dans les variables UEFI.
Le chemin qui y est associé est /EFI/Microsoft/Boot/bootmgfw.efi (relativement à /boot), sauf que si on fait un coup de tree dans le dossier EFI aucun fichier de ce nom n’apparait :
# cd /boot
# tree EFI
EFI
├── Boot
│ └── BOOTX64.EFI
└── gummiboot
└── gummibootx64.efi
Il va donc falloir mettre la main sur ce bootmgfw.efi et le replacer au bon endroit pour que Gummiboot nous propose à nouveau de démarrer sur Windows.
Dépannage rapide
Heureusement pour nous, Windows possède une copie de ce fichier EFI disponible sur C:\Windows\Boot\EFI\bootmgfw.efi. Il suffit donc de monter votre partition Windows et de récupérer le fichier pour le copier au bon endroit dans /boot :
# mount /dev/sda4 /mnt # mkdir -p /boot/EFI/Microsoft/Boot # cp /mnt/Windows/Boot/EFI/bootmgfw.efi /boot/EFI/Microsoft/Boot # umount /mnt
Et voilà, plus qu’à redémarrer la machine pour vérifier et effectivement Gummiboot nous a rajouté une entrée Windows Boot Manager dans sa liste, en dessous de l’entrée Arch Linux. Cependant, si on sélectionne cette nouvelle entrée, le système va essayer de démarrer et se bloquer dès le début en se plaignant d’un fichier BCD non disponible ; il va falloir lancer un live-USB Windows 8 pour pouvoir restaurer ce fichier manquant.
Pourquoi ne pas avoir lancé un live-USB Windows avant ? J’ai essayé et l’outil de dépannage est incapable de comprendre qu’il manque l’entrée EFI dans /boot mais maintenant qu’elle est présente il va pouvoir la compléter des fichiers manquants.
Une fois le live-USB lancé, il faut aller dans Dépanner l’ordinateur et naviguer vers Dépannage puis Résoudre ce qui empêche Windows de démarrer (je ne suis pas sur du nom de ces menus mais vous trouverez bien par déduction).
L’utilitaire va donc générer ce fichier BCD que l’on peut retrouver dans /boot après le passage du programme :
# cd /boot
# tree EFI
EFI
├── Boot
│ └── BOOTX64.EFI
├── gummiboot
│ └── gummibootx64.efi
└── Microsoft
└── Boot
├── BCD
├── BCD.LOG
└── bootmgfw.efi
Et voilà, on peut de nouveau booter sur Archlinux ainsi que sur Windows !
Conclusion
Ce dépannage a été l’occasion de mieux comprendre comment fonctionnait le système UEFI et les bootloaders associés qui sont bien différents ce que j’ai pu connaitre avec GRUB et le MBR.
Et avec un peu de chance, ça sera utile à quelqu’un qui rencontrera le même problème.