Dans le cas des installations en dual boot entre Windows (8 ou 10) et Linux, certaines marques imposent systématiquement le démarrage en UEFI sur « Windows Boot Manager », empêchant le lancement de Grub, et forçant par conséquent le démarrage sur Windows. Cela impose souvent de modifier la base bcd de Windows pour contourner le problème via les commandes suivantes, selon que le boot-secure est activé ou non:
bcdedit /set {bootmgr} path \efi\ubuntu\shimx64.efi bcdedit /set {bootmgr} path \efi\ubuntu\grubx64.efi
Cette commande modifie la base bcd de et redirige le démarrage de Windows vers les lanceurs de Grub, shimx64.efi ou bootx64.efi, ce qui est la solution la plus facile. Mais ce n’est pas forcément l’idéal, notamment à cause des mises à jour de Windows 10 très fréquentes qui obligent à répéter l’opération régulièrement. Et il ne faut pas faire d’erreur, car sinon, on a un bel écran bleu.
On peut peut-être procéder autrement, c’est-à-dire en remplaçant le Grub signé par la version « removable » de Grub utilisée sur les clés USB d’installation, qui elle, démarre sur toutes les marques sans exception.
1. Situation de départ : un Linux installé qui ne démarre pas.
Pour info, je crée une fausse situation de panne, ce qui n’est pas réellement le cas. La première chose à faire est d’accéder à ce Linux installé. On a deux moyens d’y parvenir.
- Soit en redémarrant via le mode avancé de W8/W10 qui va proposer Ubuntu dans les périphériques :
- aller dans paramètres ( le petit engrenage rouge ) - mise à jour et sécurité - récupération - démarrage avancé - cliquer sur " redémarrer maintenant " - choisir " utiliser un périphérique "
- Soit via le live-CD Supergrub2disk. Dans mon cas, je choisis Supergrub2disk, mon Linux étant le seul système installé. Je démarre sur Supergrub2disk, et dans le choix Everything, je choisis Mon Linux qui est détecté :
1.1 On fait d’abord un point sur les partitions :
essai@essai-virtual-machine ~ $ sudo parted -l Modèle: VMware, VMware Virtual S (scsi) Disque /dev/sda : 10,7GB Taille des secteurs (logiques/physiques): 512B/512B Table de partitions : gpt Numéro Début Fin Taille Système de fichiers Nom Fanions 6 1049kB 107MB 106MB fat32 démarrage 1 107MB 7107MB 7000MB ext4 msftdata 2 7107MB 9107MB 2000MB ext4 msftdata 3 9107MB 9607MB 500MB ntfs msftdata 4 9607MB 10,1GB 500MB ntfs msftdata 5 10,1GB 10,7GB 629MB ext4 msftdata
On a bien une partition efi en fat32 (sda6), et un Linux installé sur deux partitions ext4 (sda1 et sda2). Le reste (partitions 3, 4 et 5) étant des partitions d’essais sans intérêt, traces d’un ancien tuto.
1.2. Vérification de Grub
On vérifie que nos fichiers grub sont bien présents dans le point de montage /boot/efi (si la partition efi n’est pas montée, il faudra la monter manuellement via la commande mount):
essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/ /boot/efi/efi/: ubuntu /boot/efi/efi/ubuntu: grub.cfg grubx64.efi MokManager.efi shimx64.efi
Pas de problème, les fichiers grubx64.efi et shimx64.efi sont bien là, tout comme le fichier grub.cfg qui ne fait rien d’autre que le lien vers celui de la partition Linux.
1.3. Contrôle de l’ordre de démarrage inscrit dans la Nvram du bios :
essai@essai-virtual-machine ~ $ sudo efibootmgr -v BootOrder: 0000,0001,0002,0003 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(10,0)SCSI(0,0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000 Boot0002* EFI Network ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0) Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff) Boot0004* <unknown> HD(6,800,32800,0b55b2b7-f872-4f3f-843e-9060be2416ee)File(\EFI\ubuntu\shimx64.efi)
On peut voir une erreur dans la ligne Boot0004, ce qui explique que Linux ne démarre pas tout seul. C’est l’entrée Boot0000 qui est prise par défaut.
Inutile de tenter de réparer si le bios /uefi du PC est la cause du blocage et qu’aucune option de permet d’ajouter cette entrée dans ce bios. On reviendra toujours automatiquement à cette situation.
2. Suppression de Grub signé
On va désinstaller les deux paquets qui permettent de lancer Linux avec les commandes suivantes
2.1 Suppression de grubx64.efi
essai@essai-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 848 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... 152448 fichiers et répertoires déjà installés.) Suppression de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
2.2. Suppression de shimx64.efi
essai@essai-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 848 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... 152440 fichiers et répertoires déjà installés.) Suppression de shim-signed (1.19~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) ...
2.3 Suppression de l’entrée inutile dans la Nvram du bios
essai@essai-virtual-machine ~ $ sudo efibootmgr -b 0004 -B
BootOrder: 0000,0001,0002,0003
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
2.4 Suppression de traces des fichiers dans la partition efi
essai@essai-virtual-machine ~ $ sudo rm -rf /boot/efi/efi/ubuntu
On vérifie le résultat : la partition efi est entièrement vide.
essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/
/boot/efi/efi/:
3. Réparation du démarrage en vue d’un boot simulant l’USB
3.1. Installation de la version removable de Grub
essai@essai-virtual-machine ~ $ sudo grub-install --removable Installing for x86_64-efi platform. Installation terminée, sans erreur.
3.2. On vérifie qu’une nouvelle version de Grub s’est bien ajoutée à la notre partition efi
essai@essai-virtual-machine ~ $ ls -R /boot/efi/efi/ /boot/efi/efi/: BOOT /boot/efi/efi/BOOT:BOOTX64.EFI
On constate que le dossier est nommé cette fois boot et le fichier bootx64.efi.
On met à jour notre grub, par acquis de conscience.
essai@essai-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 fait
On peut en principe s’arrêter ici. Les Bios bloqués pour booter sur /efi/boot/bootx64 seront dorénavant capables de démarrer et ils lanceront notre Linux ou notre dual-boot.
Il nous reste à vérifier le démarrage de notre Linux.
Le résultat de efibootmgr au redémarrage est le suivant :
essai@essai-virtual-machine ~ $ sudo efibootmgr -v
[sudo] password for essai:
BootCurrent: 0000
BootOrder: 0000,0001,0002,0003
Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(10,0)SCSI(0,0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000
Boot0002* EFI Network ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0)
Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff)
essai@essai-virtual-machine ~ $
5. Remarque importante.
Rien ne garantit que cette manipulation pourra résoudre le problème du blocage de Bios sur toutes les marques et dans tous les cas. Il faudrait que de « joyeux cobayes » se risquent à tester le résultat de tout cela sur de vrais PC bloqués (comme les HP ou les Toshiba).
Quoi qu’il en soit, il est aisé de réinstaller les versions signées de grub via les commandes pour revenir à la version initiale (toujours depuis SG2D ou le démarrage avancé de W10):
sudo apt-get install -y grub-efi-amd64-signed shim-signed
sudo update-grub
Les deux commandes recréeront automatiquement et sans intervention :
- Les entrées dans le bios/uefi et les placeront en tête.
- Le dossier /efi/ubuntu avec les fichiers grub nécessaires.
- La mise à jour de grub.cfg tant dans la partition Linux que dans la partition efi.
On pourra, si on le souhaite, supprimer comme suit les traces de notre grub removable, mais ce n’est pas indispensable :
essai@essai-virtual-machine ~ $ sudo rm -rf /boot/efi/EFI/BOOT
Voir discussion au sujet de cette démo ici.
*******************************************
5. Annexe : proposée simplement à titre informatif.
5.1. Possibilité complémentaire : ajout d’une entrée dans le bios
Pour information, j’explique comment on pourrait ajouter une entrée supplémentaire dans la liste de démarrage, si éventuellement on en avait un besoin particulier.
essai@essai-virtual-machine ~ $ sudo efibootmgr --create --part 6 --label "Linux removable" --loader '\efi\boot\bootx64.efi' BootOrder: 0004,0000,0001,0002,0003 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) Boot0002* EFI Network Boot0003* EFI Internal Shell (Unsupported option) Boot0004* Linux removable
A noter qu’en principe, cette opération est faisable depuis le bios lui-même.
Ma partition efi étant la partition 6, je respecte ce nombre. Je fais pointer la nouvelle entrée vers le nouveau fichier grub dans \efi\boot\bootx64.efi. Notre entrée s’est ajoutée en tête de liste dans l’ordre de boot. On met à jour notre grub, par acquis de conscience.
essai@essai-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 fait
Il nous reste à vérifier le démarrage de notre Linux.
5.2. Résultat des modifications
Notre Linux démarre sans encombre, et il ne reste plus qu’à vérifier que l’ordre de démarrage confirme ce succès.
essai@essai-virtual-machine ~ $ sudo efibootmgr -v BootCurrent: 0004 BootOrder: 0004,0000,0001,0002,0003 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(10,0)SCSI(0,0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(5,0)03120a00010000000000 Boot0002* EFI Network ACPI(a0341d0,0)PCI(11,0)PCI(1,0)MAC(000c2900b41b,0) Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff) Boot0004* Linux removable HD(6,800,32800,0b55b2b7-f872-4f3f-843e-9060be2416ee)File(\efi\boot\bootx64.efi)
Notre Linux vient bien de démarrer sur notre entrée nouvellement créée… Il utilise le fichier bootx64.efi .