Archives mensuelles : septembre 2016

Installer un Linux bootable tant en Legacy qu’en uefi

C’est plus un exercice qu’un véritable tutoriel, mais certains se sont penchés sur cette question : peut-installer un Linux qui puisse booter tant en Legacy qu’en Uefi ? La réponse est clairement oui.

Pour la démo, j’utilise une Mint 17, mais c’est adaptable assez aisément à toutes les distributions.

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  pour anticiper la suite de mon installation, mais on pourrait parfaitement la créer a posteriori. Voici une capture faite avec gparted :

gparted

Une partition fat32 avec le drapeau boot est présente (je l’ai créée volontairement). Et l’installation en mode Legacy a ajouté spontanément une partition bios-boot (nommée ici bios_grub).

Et le résultat d’un boot-info : Boot-info initial.

On note une installation somme toute classique en Legacy, si ce n’est que le disque est au format gpt. La partition es totalement vide, ce qui bien sûr va empêcher de booter en uefi. On va le vérifier.

(la réparation finale est le résultat d’un retour à ce Linux purement Legacy, après un autre test- donc, sans intérêt pour nous)

II) Tentative de boot en uefi

Nous basculons notre bios en UEFI. Le résultat est édifiant. Notre Mint n’est pas capable de démarrer en UEFI :

boot-planté
(Les entrées en échec sont les résidus d’anciens tests, que j’ai négligé de supprimer dans le bios.)

III)  Démarrage en UEFI grâce à SG2D

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 modification. On voit qu’il me permet de booter sur deux noyaux différents. Nous allons simplement choisir de démarrer sur l’entrée Ubuntu qui est proposée.

SG2D

Nous obtenons un bureau fonctionnel en UEFI. L’occasion de faire un second boot-info avant réparation.

Nous constatons que nous sommes bien en uefi, et que boot-repair est impuissant pour proposer une réparation efficace, puisqu’il ne détecte pas la partition efi qui est pourtant présente.

Le boot de votre PC est en mode EFI, mais aucune partition EFI n'a été détectée. Vous voudrez peut-être re-essayer après avoir créé une partition EFI (FAT32, 100MB~250MB, en début de disque, drapeau boot)./pre>

IV) La réparation de grub pour booter en UEFI

On va donc suppléer à cette faiblesse et réparer notre grub pour qu’il boote en Uefi grâce à une série de commandes. Les voici :

essai@essai-virtual-machine ~ $ sudo mount /dev/sda1 /boot/efi
[sudo] password for essai: 
essai@essai-virtual-machine ~ $ sudo apt-get install 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 ont été installés automatiquement et ne sont plus nécessaires :
  libefivar0 mokutil sbsigntool shim
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés : 
  grub-efi-amd64 grub-efi-amd64-bin
Paquets recommandés :
  secureboot-db
Les paquets suivants seront ENLEVÉS :
  grub-gfxpayload-lists grub-pc
Les NOUVEAUX paquets suivants seront installés :
  grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed
0 mis à jour, 3 nouvellement installés, 2 à enlever et 74 non mis à jour.
Il est nécessaire de prendre 0 o/939 ko dans les archives.
Après cette opération, 5 295 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Préconfiguration des paquets..
(Lecture de la base de données... 181079 fichiers et répertoires déjà installés.)
Suppression de grub-gfxpayload-lists (0.6) ...
Suppression de grub-pc (2.02~beta2-9ubuntu1.12) ...
Traitement des actions différées (« triggers ») pour man-db (2.6.7.1-1ubuntu1) ...
Sélection du paquet grub-efi-amd64-bin précédemment désélectionné.
(Lecture de la base de données... 181060 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../grub-efi-amd64-bin_2.02~beta2-9ubuntu1.12_amd64.deb ...
Dépaquetage de grub-efi-amd64-bin (2.02~beta2-9ubuntu1.12) ...
Sélection du paquet grub-efi-amd64 précédemment désélectionné.
Préparation du dépaquetage de .../grub-efi-amd64_2.02~beta2-9ubuntu1.12_amd64.deb ...
Dépaquetage de grub-efi-amd64 (2.02~beta2-9ubuntu1.12) ...
Sélection du paquet grub-efi-amd64-signed précédemment désélectionné.
Préparation du dépaquetage de .../grub-efi-amd64-signed_1.34.14+2.02~beta2-9ubuntu1.12_amd64.deb ...
Dépaquetage de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
Paramétrage de grub-efi-amd64-bin (2.02~beta2-9ubuntu1.12) ...
Paramétrage de grub-efi-amd64 (2.02~beta2-9ubuntu1.12) ...
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
Paramétrage de grub-efi-amd64-signed (1.34.14+2.02~beta2-9ubuntu1.12) ...
essai@essai-virtual-machine ~ $ sudo grub-install --target=x86_64-efi
Installation pour la plate-forme x86_64-efi
Installation terminée, sans erreur.
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 ~ $

On a d’abord monté la partition sda1 dans boot/efi, puis installé les paquets grub pour l’uefi (je me limite à grubx64.efi car Vmware n’ayant pas de boot-secure n’a pas besoin de shimx64.efi), et enfin, on a lancé une réparation de grub (l’option –target=x86_64-efi est probablement superflue.

Après un redémarrage, c’est l’occasion de faire une dernier boot-info, pour voir la situation finale

Une seule chose est gênante : la partition efi n’est pas montée dans /etc/fstab (ici, elle est placée en commentaire). On va donc forcer son montage en éditant le fichier fstab via la commande sudo gedit /etc/fstab et supprimer le # sur la ligne concernée (la dernière, dans mon cas).
fstab

(quelques entrées bizarres dans efibootmgr -v sont les traces d’essais précédents que j’ai eu la flemme de supprimer. Donc, ils sont sans importance)

Il ne reste plus qu’à redémarrer en UEFI pour voir si Mint va se lancer en UEFI.  Aucun problème :  Grub affiche son menu et Mint boote correctement.

boot-uefi

V) Tentative de boot en Legacy.

On repasse en mode bios-legacy. On vérifie que les entrées fonctionnent. En effet.

boot-bios

D’ailleurs, tout cette démo est tapée dans ce mode Legacy. J’ai donc une Mint qui fonctionne aussi bien en Legacy qu’en UEFI.

Réparer une Installation Linux en Legacy sur disque GPT

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):
départ 1

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.

Sgrub2

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é.

resultat

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)

 

 

Les Tutoriels concernant Linux

linux1

Les distributions Linux sont de plus en plus nombreuses et nombre d’utilisateurs sont disposés à tenter « l’expérience du pingouin ».

Et c’est souvent avec bonheur, tant des distributions comme Ubuntu (et ses variantes), Mint, Fedora et autres sont aujourd’hui en mesure de tenir la dragée haute à Windows.

Les tutoriels étant très nombreux, je propose plutôt des « expériences personnelles », pour la plupart réalisées en uefi et sur PC virtuel.

Installer Ubuntu / Mint à partir de Windows en UEFI sans DVD ni USB

Certains ayant réfléchi à l’installation d’un Windows sans DVD ni USB depuis un Linux, je me suis dit qu’il serait intéressant d’envisager l’inverse, la présence d’un Windows préinstallé étant plus courante que celle d’un Linux initial. Je m’appuie sur un W8 installé en UEFI pour l’exemple et sur une Mint 17 à installer sans support externe.

I) Situation de départ : créer un espace pour le contenu de l’iso Mint.

La situation de départ est la suivante :

Heberger image

On va réduire la dernière partition de 2,5 Gb pour pouvoir créer une nouvelle partition :

Heberger image

Aucune difficulté jusque-là. Windows permet de gérer tout ça sans problème.

Nb. Je ne libère pas d’espace pour le futur Linux, car mon intention n’est pas de l’installer… Je me limite à montrer le processus.

La partie la plus délicate est celle qui suit, car il faut créer une seconde partition efi en fat32 pour y héberger le contenu de notre ISO de Mint, et là l’invite de commandes va servir : on l’exécute via les touches Windows et X pour obtenir l’invite de commandes en admin :

Heberger image

dikspart
sel disk 0
create partition efi
format fs=fat32 quick
assign letter=u
exit

Nous venons simplement de créer une partition efi  formatée en fat32 sur l’espace libre, et de lui attribuer la lettre U. Nous constatons que cette lettre U n’apparaît pas dans le gestionnaire de disques. Il faudra alors utiliser l’invite de commandes pour y accéder.

II) Copie du contenu de l’iso de Mint vers la nouvelle partition efi.

Pour décompresser l’ISO de Mint, on a trois moyens simples :

  • On la monte par clic droit  (les Ws récents permettent de le faire) et on copie le contenu dans un dossier.
  • On ouvre le fichier ISO avec un logiciel tel que 7zip et on copie le contenu.
  • On utilise un logiciel du type « Daemon Tools » pour simuler un lecteur de disque depuis l’iso.

Sous VmWare, je me trouve dans une situation proche de la 3ième. Mon iso est décompressée dans un lecteur D.

Heberger image

Il nous suffit de copier le contenu de l’iso (mon lecteur D) vers ma partition efi (mon lecteur U). La commande est simple:

u:
xcopy /e d:

Explication : on se positionne sur le lecteur U (la nouvelle efi) et on copie tout ce qui vient de D, sous-répertoires compris, vers l’emplacement actuel. Le résultat est le suivant (vu par un dir):

Heberger image

Notre live-partition de Mint est prête. Il ne reste plus qu’à faire en sorte de booter dessus.

III) Modification de l’ordre de démarrage.

En principe, les BIOS – UEFI proposent une option permettant de forcer le démarrage sur un fichier efi (onglet boot, option « boot on an efi file » ou expression proche). Mais tous les bios ne sont pas identiques. Donc, on va utiliser un logiciel permettant de faire la même chose depuis Windows, autrement dit l’équivalent graphique de la commande efibootmgr sous Linux. Ce logiciel s’appelle Easyuefi.

Heberger image

On le télécharge, on l’exécute et on lui indique qu’on veut ajouter une nouvelle entrée. On pointe sélectionne la partition efi nouvellement créée et on indique le chemin du fichier bootx64.efi. On valide. Une nouvelle entrée « GNU Linux » est créée. Il ne reste qu’à la placer en tête de liste dans l’ordre de démarrage. Là encore, Easyuefi sait faire le travail :

Heberger image
On constate que le bouton « up » a fait monter l’entrée en tête de liste. Il s’agit bien de notre fichier de démarrage pour lancer l’installation de Mint. Il ne reste qu’à vérifier par un redémarrage, sans DVD ni USB inséré, bien entendu.

IV) Vérification du boot sur la live-partition Linux

On obtient bien le menu noir et blanc annonçant qu’on va démarrer en uefi.

Heberger image

Une fois Mint lancé, on constate qu’on a bel et bien l’option d’installation, et un sudo efibootmgr -v (à noter que j’ai dû l’installer sur la live-partition) confirme que notre installation fonctionne dans l’ordre souhaité.

Heberger image

On n’a plus qu’à lancer l’installation si on le souhaite. Dans mon cas, si je veux redonner la main à mon W8-10, la commande suivante rendra à Windows cette priorité.

sudo efibootmgr -o 0002,0006

Au terme de l’installation, je conseillerais personnellement de supprimer la seconde partition efi et de supprimer l’entrée devenue inutile. Ca évitera les surprises. En outre, cette technique n’a de sens que pour le cas où on serait dans l’impossibilité d’utiliser un DVD ou une clé USB.

Créer un triple boot en uefi

1. Présentation de la situation

Si le principe d’associer 2 Windows et un Linux n’est pas compliqué en soi, le souci réside dans le résultat : Grub va s’installer dans la partition efi et proposer un menu de ce genre :

1. Ubuntu.
2. Ubunty Recovery
3. Windows Boot Manager

Pourquoi  un seul Windows ? Tout simplement parce que grub cherche le fichier bootmgfw.efi dans le dossier /efi/Microsoft/boot de la partition efi. Il faudra donc lancer WBM pour enfin obtenir le choix entre les deux versions de Windows de son dual-boot. C’est fonctionnel, mais lourd. Comment éviter cela ?

2. Situation de départ  un double boot Windows en uefi.

Ici, il s’agit de W10 /W7 (voir ce tuto d’installation), mais c’est pareil pour W10 et W8. On fait un état du gestionnaire de disque et des fichiers de démarrage depuis W10.

Heberger image

On voit que c’est W10 qui commande le dual-boot. W10 est installé sur C, et W7 est placé sur D.

3. Création d’une seconde partition efi.

Pour rendre le triple boot possible, il va falloir créer une seconde partition efi pour faire comprendre à grub qu’on a deux lanceurs windows différents, un peu comme si on avait deux disques durs différents. L’déal serait de créer la seconde partition efi avant le disque C. Mais pour mon exemple, je vais la placer après.

On réduit donc la partition C pour créer un espace libre  de 200 Mo, et on passe en invite de commandes. La série suivante permet de créer une nouvelle partition efi et de lui attribuer la lettre Z:

C:\windows\system32>diskpart
Microsoft DiskPart version 10.0.10240
Copyright (C) 1999-2013 Microsoft Corporation.
Sur l’ordinateur : DESKTOP-I2H691G

DISKPART> sel disk 0
Le disque 0 est maintenant le disque sélectionné.

DISKPART> create partition efi
DiskPart a réussi à créer la partition spécifiée.

DISKPART> format fs=fat32
  100 pour cent effectués
DiskPart a formaté le volume.

DISKPART> assign letter=z
DiskPart a correctement assigné la lettre de lecteur ou le point de montage.

DISKPART>exit
C:\windows\system32>

Heberger image

On a donc maintenant une nouvelle partition efi système de 200 Mo

4. Création des fichiers de démarrage.

La commande bcdboot, tapée depuis Windows 10, va se limiter à la copie des fichiers depuis /windows/system32/ vers la partition efi. Il suffit donc de faire les bons choix. Dans mon cas, la commande est simple :

bcdboot d:\windows /l fr-FR /s z:
Les fichiers ont été correctement créés

On a copié les fichiers de démarrage de W7 dans la nouvelle partition. La commande ne cherche pas d’autre version de Windows, ce qui nous convient bien. On vérifie via une série de dir :
Heberger image

La vérification via la commande dir montre bien que les fichiers sont correctement créés. En revanche, la commande bcdedit /v montre que c’est toujours la première partition efi qui commande le démarrage. Un extrait pour preuve :

C:\windows\system32>bcdedit /v
Gestionnaire de démarrage Windows
---------------------------------
identificateur          {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

Chargeur de démarrage Windows
-----------------------------
identificateur          {355f51c7-6862-11e6-bcf1-a302a5269f7a}
device                  partition=C:
path                    \windows\system32\winload.efi
description             Windows 10

Chargeur de démarrage Windows
-----------------------------
identificateur          {355f51c8-6862-11e6-bcf1-a302a5269f7a}
device                  partition=D:
path                    \windows\system32\boot\winload.efi
description             Windows 7

Un redémarrage va confirmer que nous avons toujours notre dual-boot Windows. Rien n’a changé en apparence (mais il serait facile maintenant, depuis le bios, de faire démarrer W7 tout seul).  On laisse comme cela pour l’instant, et on va lancer l’installation de notre Linux.

5. Installation de Linux.

Comme pour un dual-boot, on lance la clé usb en uefi et on fait un point avec gparted et sudo parted. On voit bien les deux partitions efi et le drapeau boot qui leur est associé.

Heberger image

J’ai préparé un espace libre de 10 Gb sur mon second disque dur (/dev/sdb) pour y placer ma Linux Mint. Je choisis le partitionnement manuel via « autre chose ». Je choisis l’espace libre et je m’assure que grub va bien s’installer dans le premier disque (dans mon cas /dev/sda). Pas de problème, on peut installer notre Linux. Rien de particulier dans cette installation qui s’avère tout à fait classique.

Au redémarrage, on constate que Grub nous propose deux windows boot manager.

Heberger image

La première des deux entrées WBM exécute notre précédent dual-boot (et propose toujours un choix W10/W7). La seconde entrée proposée par Grub lance directement W7.

Heberger imageHeberger image

Il ne va donc nous rester qu’à rendre tout ça lisible en modifiant l’appellation des entrées et en supprimant le dual-boot W10 /W7 devenu inutile.

6. Suppression du dual-boot de Windows

On va utiliser la commande bcdedit depuis Windows 10 pour supprimer notre entrée W7 inutile et masquer ce menu. On a vu plus haut que l’identificateur de W7 est {355f51c8-6862-11e6-bcf1-a302a5269f7a}. Donc :

c:\windows\system32>bcdedit /delete {355f51c8-6862-11e6-bcf1-a302a5269f7a}
L'opération a réussi.

c:\windows\system32>bcdedit /set {bootmgr} displaybootmenu no
L'opération a réussi.

Chaque Windows est devenu indépendant, et Grub se charge de le lancer;

7. Renommer les entrées de Grub.

On pourrait le faire depuis chaque Windows, mais je préfère bricoler le moins possible la base bcd. On va donc modifier grub pour lancer les Windows avec le nom qui nous convient. On édite le contenu du fichier /boot/grub/grub.cfg. On copie le contenu de la section 30_OS-prober. Dans mon cas :

Heberger image

On édite le fichier /etc/grub.d/40-custom et on copie le contenu en modifiant l’intitulé des deux entrées mises en relief en vert.

Heberger image

Il ne reste plus qu’à désactiver 30_os-prober et à faire un sudo update-grub.

sudo chmod -x /etc/grub.d/30_os-prober
sudo update-grub

Le redémarrage confirme que la modification s’est bien effectuée. Chaque Windows se lance directement avec le bon intitulé.

Heberger image

Nous avons bien un triple boot intégralement géré par Grub. Le lanceur de Windows n’apparaît plus.

8. Bilan

Voilà ce que montre easyuefi  (installé sur Seven):

Heberger image

Grub est bien installé sur sda2, comme le lanceur W10. En revanche, seul le lanceur W7 est sur sda5. Confirmation avec un sudo efibootmgr -v

essai@essai-virtual-machine ~ $ sudo efibootmgr -v
[sudo] password for essai: 
BootCurrent: 0006
Timeout: 2 seconds
BootOrder: 0006,0007,0004,0000,0001,0002,0003,0005
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(000c29a6acae,0)
Boot0003* EFI Internal Shell (Unsupported option)	MM(b,3efcb000,3f355fff)
Boot0004* Windows Boot Manager	HD(2,e1800,64000,8ef6bf0b-b1e3-447a-89f9-61194292d2e2)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.}...f................
Boot0005* EFI VMware Virtual SCSI Hard Drive (2.0)	ACPI(a0341d0,0)PCI(15,0)PCI(0,0)SCSI(2,0)
Boot0006* ubuntu	HD(2,e1800,64000,8ef6bf0b-b1e3-447a-89f9-61194292d2e2)File(\EFI\ubuntu\shimx64.efi)
Boot0007* Windows Boot Manager	HD(5,2673800,64000,52e030eb-32e7-41a7-b4ba-cf293db78a9a)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.}....................
essai@essai-virtual-machine ~ $