Beaucoup de ceux qui veulent installer une distribution Linux sur une PC UEFI préinstallé avec Windows 8 ou 10 commettent l’erreur de passer le BIOS en Legacy ou d’activer l’option « Lauch-csm ». Ca a pour incidence de conduire à une installation boiteuse :
- Windows fonctionne en UEFI.
- Linux fonctionne en Legacy.
Donc, pas de double-boot et une obligation de passer par le bios à chaque fois.
I) Situation de départ
On règle son PC pour booter en Legacy. On installe volontairement une Linux Mint sur un disque gpt (on peut faire ça avec gparted) en faisant booter le Live-USB en mode Legacy. Pour la démonstration, j’ai ajouté une partition efi dès le départ (puisque si on a une Windows, elle préexiste), mais on pourrait parfaitement la créer a posteriori.
La structure est la suivante (une partition efi côtoie une partition bios-boot):
Cela nous donne le résultat suivant : Boot-info initial. On constate qu’on a bien un grub installé dans le mbr :
=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector
194560 of the same hard drive for core.img. core.img is at this location
and looks for (,gpt3)/boot/grub. It also embeds following components:
Le disque est bien au format gpt. Une partition EFI est bien présente puisqu’on l’a créée, mais une partition bios-boot a été ajoutée.
Disk /dev/sda: 32.2 GB, 32212254720 bytes 255 heads, 63 sectors/track, 3916 cylinders, total 62914560 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes Partition Boot Start Sector End Sector # of Sectors Id System /dev/sda1 1 62,914,559 62,914,559 ee GPT GUID Partition Table detected. Partition Attrs Start Sector End Sector # of Sectors System /dev/sda1 + 2,048 194,559 192,512 EFI System partition /dev/sda2 194,560 202,751 8,192 BIOS Boot partition /dev/sda3 202,752 19,945,471 19,742,720 Data partition (Linux) /dev/sda4 19,945,472 21,899,263 1,953,792 Swap partition (Linux)
On a bien une Mint installée en mode Legacy :
=================== UEFI/Legacy mode:
This installed-session is not in EFI-mode.
La partition efi est désespérément vide :
sda1: File system: vfat
Boot sector type: Windows 8/2012: FAT32
Boot sector info: No errors found in the Boot Parameter Block.
Operating System:
Boot files:
Boot-Repair nous propose même une réinstallation de grub dans le mbr pour le cas où nous aurions des problèmes.
=================== Suggested repair
The default repair of the Boot-Repair utility would reinstall the grub2 of sda3 into the MBR of sda.
II) Réparation avec Supergrub2disk
Nous basculons notre bios en UEFI. Notre Mint n’étant pas capable de démarrer en UEFI, nous allons lui donner un petit coup de pouce. Le live-cd Supergrub2disk va nous permettre de faire démarrer ce Linux malgré tout, ce qui va grandement nous simplifier les choses pour la future réparation. On voit qu’il me permet de booter sur deux noyaux différents. Le premier fera l’affaire.
Comme Boot-Repair ajoute mille merdouilles, et fait des copies plus ou moins heureuses de fichiers avec des backup dont on ne comprend pas vraiment l’utilit », on va éviter de s’en servir.
1. Commençons par nous assurer que nous sommes bien en uefi. Pas de problème
essai@essai-virtual-machine ~ $ [ -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD" EFI boot on HDD
2. On supprime la version de grub installée par erreur lors de l’installation en legacy:
essai@essai-virtual-machine ~ $ sudo apt-get autoremove grub-pc-bin [sudo] password for essai: 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-gfxpayload-lists grub-pc grub-pc-bin libefivar0 mokutil sbsigntool shim 0 mis à jour, 0 nouvellement installés, 7 à enlever et 846 non mis à jour. Après cette opération, 6 755 ko d'espace disque seront libérés. Souhaitez-vous continuer ? [O/n] o (Lecture de la base de données... 181581 fichiers et répertoires déjà installés.) Suppression de mokutil (0.3.0-0ubuntu3~14.04.1) ... Suppression de libefivar0:amd64 (0.21-1~14.04.2) ... Suppression de sbsigntool (0.6-0ubuntu7.2) ... Suppression de shim (0.8-0ubuntu2) ... Suppression de grub-pc (2.02~beta2-9ubuntu1.12) ... Suppression de grub-pc-bin (2.02~beta2-9ubuntu1.12) ... Suppression de grub-gfxpayload-lists (0.6) ... Traitement déclenché pour man-db (2.6.7.1-1) ... Traitement déclenché pour libc-bin (2.19-0ubuntu6) ...
3. A ce stade, il est nécessaire de monter (autrement dit, rendre accessible) la partition efi pour que notre nouveau Grub puisse y écrire ses futurs fichiers (la partition 1 du premier disque est montée dans le dossier /boot/efi):
essai@essai-virtual-machine ~ $ sudo mount /dev/sda1 /boot/efi
4. Il faut installer les paquets nécessaires pour que grub puisse être mis à jour :
essai@essai-virtual-machine ~ $ sudo apt-get install -y --force-yes grub-efi-amd64-signed shim-signed
La commande va installer trois paquets contenant mokmanager.efi, shimx64.efi et grubx64.efi. C’est parti :
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 : grub-efi-amd64 grub-efi-amd64-bin libefivar0 linux-signed-image-3.13.0-96-generic linux-signed-image-generic mokutil sbsigntool shim Paquets recommandés : secureboot-db Les NOUVEAUX paquets suivants seront installés : grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed libefivar0 linux-signed-generic linux-signed-image-3.13.0-96-generic linux-signed-image-generic mokutil sbsigntool shim shim-signed 0 mis à jour, 11 nouvellement installés, 0 à enlever et 846 non mis à jour. Il est nécessaire de prendre 0 o/1 822 ko dans les archives. Après cette opération, 10,6 Mo d'espace disque supplémentaires seront utilisés. Préconfiguration des paquets...
Ici, j’abrège une peu la liste…
Installation terminée, sans erreur.
5. Tout est prêt pour qu’on puisse lancer la réparation de grub.
essai@essai-virtual-machine ~ $ sudo update-grub
Création du fichier de configuration GRUB…
Found linux image: /boot/vmlinuz-3.13.0-96-generic
Found initrd image: /boot/initrd.img-3.13.0-96-generic
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
essai@essai-virtual-machine ~ $
Tout semble s’être bien passé.
6. Vérifions avec un petit Boot-info-uefi:
Les fichiers grub ont bien été écrits sur la partition efi :
sda1: File system: vfat
Boot sector type: Windows 8/2012: FAT32
Operating System:
Boot files: /EFI/ubuntu/MokManager.efi /EFI/ubuntu/grubx64.efi
/EFI/ubuntu/shimx64.efi
La partition efi est montée dans le fichier fstab mais la ligne est commentée. On va donc enlever le dièse pour ne pas avoir de message d’erreur au démarrage en passant par sudo gedit /etc/fstab afin de le modifier :
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
#UUID=04BA-962F /boot/efi vfat defaults 0 1
Mon installation est bien reconnue comme étant en uefi :
boot-info is executed in installed-session (Linux Mint 17 Qiana, qiana, LinuxMint, x86_64) BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session. sda : GPT, BIOS_boot, has-correctEFI, not-usb, has-os, 2048 sectors * 512 bytes
Et j’ai évité certaines options douteuses proposées par boot-repair :
=================== Suggested repair
The default repair of the Boot-Repair utility would reinstall the grub-efi-amd64-signed of sda3, using the following options: sda1/boot/efi,
Additional repair would be performed: unhide-bootmenu-10s use-standard-efi-file rename-ms-efi
7. Un seul point me semble insatisfaisant : celui-ci
=================== efibootmgr -v BootCurrent: 0004 BootOrder: 0004,0005,0000,0001,0002,0003 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(4,0)03120a00010000000000 Boot0002* EFI Network ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(000c29b06483,0) Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff) Boot0004* ubuntu HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(EFIubuntushimx64.efi) Boot0005* Boot0005 ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0)HD(3,800,32000,00074fc0)File(EFIubuntushimx64.efi)
Je n’ai pas besoin de démarrer avec shimx64.efi, puisque VMware n’a pas de secure-boot. Je vais modifier ça pour démarrer avec grubx64.efi en ajoutant une nouvelle entrée vers ce fichier :
sudo efibootmgr --create --part 1 --label "Ubuntu non signé" --loader '\efi\ubuntu\grubx64.efi
Le résultat est le suivant :
essai@essai-virtual-machine ~ $ sudo efibootmgr -v [sudo] password for essai: BootCurrent: 0007 BootOrder: 0006,0000,0001,0002,0003,0005,0004 Boot0000* EFI VMware Virtual SCSI Hard Drive (0.0) ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0) Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0) ACPI(a0341d0,0)PCI(11,0)PCI(4,0)03120a00010000000000 Boot0002* EFI Network ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(000c29b06483,0) Boot0003* EFI Internal Shell (Unsupported option) MM(b,3efcb000,3f355fff) Boot0004* ubuntu HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\EFI\ubuntu\shimx64.efi) Boot0005* Boot0005 ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(0,0)HD(3,800,32000,00074fc0)File(\EFI\ubuntu\shimx64.efi) Boot0006* Ubuntu non signé HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\efi\ubuntu\grubx64.efi) essai@essai-virtual-machine ~ $
Ma Linux Mint est parfaitement opérationnelle pour démarrer en UEFI… Ce qu’elle va faire.
III) Meme réparation depuis un live-cd (à venir)