La démonstration est réalisée avec un PC virtuel sous W10 installé en UEFI sur disque gpt. La situation étant assez courante, autant en faire une simulation.

Attention: si des données ont été écrites sur telle ou telle partition, la récupération ne sera plus possible. On récupérera des partitions incomplètes, et le système ne fonctionnera plus.

1. Situation de départ : une Linux Mint 17.1 installée sur disque gpt uefi

On constate que l’installation est faite en uefi (une partition efi contient le drapeau boot). Le nombre de partitions principales est de six. Le disque est au format gpt. On va donc casser tout ça pour la démonstration.

Avec gparted, présent sur le live-cd Linux, je crée une nouvelle table de partitions ms-dos (autrement dit mbr). Je vais y placer 2 partitions NTFS de taille aléatoire :

Le résultat est le suivant : mon disque est passé en mode ms-dos. Mon Linux est complètement passé à la trappe. Comment réparer tout ça ?

2. Récupération des partitions avec Minitool Partition Wizard disque

C’est un LiveCD qu’on trouve au format iso ici : https://www.partitionwizard.com/partition-wizard-bootable-cd.html

Il suffira de décompresser le contenu de l’image iso de la version 64 bits sur une clé usb formatée en fat32 et rendue bootable, avec Rufus par exemple, ou manuellement pour pouvoir démarrer dessus en mode uefi.

• Voir ce lien pour créer la clé bootable depuis Windows.
• Depuis Linux, il suffira de formater la clé en fat32, d’y décompresser l’iso, et d’ajouter le drapeau boot depuis Gparted à la partition concernée.

Une fois la clé faite et le démarrage réussi, on aboutira à un bureau de ce genre :

La première chose que nous allons faire, c’est de reconvertir le disque au format gpt. L’onglet disk contient une option de conversion. Il suffit bêtement de l’appliquer pour que le disque soit converti, sans perte de donnée. On voit sur l’image précédente le résultat de cette conversion.

A ce stade, on va pouvoir faire une recherche des partitions effacées grâce à l’option « restore partition« . Une première recherche rapide n’aboutissant qu’à afficher mes partitions NTFS, on va faire une recherche approfondie :

Le logiciel a trouvé une vingtaine de partitions… comment choisir ? Je constate que la seconde partition formatée en ext4 contient 4,65 Gib de fichiers. C’est ce qu’occupe le système Linux (une vérification du contenu le confirme). En la sélectionnant, on va griser automatiquement  toutes les partitions qui ne sont pas en accord avec ce choix. Il ne reste plus qu’à chercher parmi celles qui restent les partitions manquantes (on peut également se référer aux secteurs de démarrage et de fin pour être sûr que c’est cohérent) :

Les choix sur l’image précédente créent un ensemble cohérent. Il ne reste qu’à valider tout ça. Le seul bémol, c’est que Partition Wizard ne parvient pas à retrouver la partition efi formatée en fat32.

Ça signifie 3 choses :

• Il va falloir la recréer.
• Il va falloir réinstaller grub2 pour que Linux Mint puisse démarrer.
• Il faudra modifier une ligne dans le fichier /etc/fstab pour supprimer une erreur de montage de partition.

3. Récupération des partitions avec Gdisk et Testdisk

L’inconvénient de la première réparation est d’obliger à l’utilisation d’un outil externe au liveCD Linux. On peut trouver des outils purement Linux qui aboutissent au même résultat. Partons de la même situation : une installation Linux a été effacée par un formatage indésirable :

3.1. Passage de la partition en gpt avec gdisk

On va commencer par supprimer nos deux partitions inutiles depuis gparted, afin qu’elles ne nous gênent pas (gdisk peut renvoyer un message d’erreur si les partitions sont mal positionnées).  Puis on installe le premier outil nécessaire : gdisk (il est préinstallé par défaut sur les dernières versions) .

Si ce n’est pas le cas, on s’assure que le PC est connecté à Internet. On installe et on lance gdisk pour convertir le disque /dev/sda.

sudo apt-get install gdisk
sudo gdisk /dev/sda

On convertit simplement le disque en gpt par la lettre W. Gdisk convertit le disque sans problème. Le tout est résumé sur cette image, avec une vérification via sudo parted -l :

3.2. Récupération des partitions via testdisk.

On commence par l’installer :

sudo apt-get install testdisk
sudo testdisk

On choisis les options suivantes :

- No Log
- Disk /dev/sda
- [EFI-GPT]
- Analyse 
- Quick Search

Comme avec Minitool Wizard, Testdisk ne voit que les partitions NTFS en mode quick search. On va donc passer par un Deeper Search en faisant « entrée » (il peut prendre pas mal de temps). Le résultat est un peu obscur : on obtient une liste plutôt longue et peu parlante de fichiers MS data.

Les deux premières lignes sont écartées d’office, puisque ce sont mes partitions NTFS. A partir de la 3 ième la lettre P permet de voir si des fichiers sont présents. La 4 ième ligne est satisfaisante. Mon Linux semble bien être là.

Nous la sélectionnons avec les flèches gauche et droite pour lui attribuer la lettre P (elle passe en vert). Cette partition se termine au secteur 13881343. Inutile de vérifier tout ce qui commence avant ce secteur, car nous risquerions un chevauchement de partitions. PgUP /PgDn permet de chercher dans la liste une partition commençant après cette zone :

La partition suivante contient elle aussi des fichiers… c’est mon /home. Et on procède ainsi de suite jusqu’à la fin du disque. J’ai retrouvé une nouvelle fois 5 partitions.

Il ne reste plus qu’à finaliser par « entrée » et à écrire avec « w » qu’on confirme par « y« .. Nous pouvons contrôler le résultat et vérifier l’absence de chevauchement. Testdisk nous demande de redémarrer.

A nouveau, nous n’avons pas pu récupérer la partition efi. Nous avons donc les trois mêmes opérations à faire pour finaliser la réparation. 

4. Réparation du démarrage de Grub (pour les deux cas)

Pour simplifier les choses, on va utiliser le logiciel SuperGrub2 Disk pour faire démarrer notre Linux.

On pourrait le faire en chrootant depuis le live-cd (ce qui exclurait tout logiciel tiers): cette technique est expliquée ici.

Le démarrage en UEFI conduit à ces fenêtres. On sélectionne Everything, et pour ne pas se compliquer la vie, on choisit le premier noyau valable.

Le système se lance en mode texte jusqu’à un message d’erreur évoquant un problème de montage de partition. On choisit « S » pour ignorer le problème. On aboutit au bureau de notre Mint installée. On fait un état des lieux avec Gparted:

On va créer sur l’espace libre en début de disque une partition qu‘on formate en fat32. On lui ajoute le drapeau boot (par clic droit) pour qu’elle soit reconnue comme étant « système ».

Avec les Ubuntu et Mint récents, on peut même cocher « esp » pour la rendre purement efi.

On va pouvoir réparer notre démarrage de Mint en réécrivant les fichiers grub nécessaires :

sudo mount /dev/sda1 /boot/efi
sudo grub-install
sudo update-grub

On a monté la partition efi dans le dossier /boot/efi, on réinstalle Grub et on le met à jour.

Tout semble s’être bien passé. Notre Linux va être capable de démarrer tout seul. En effet:

Un message d’erreur prévisible informe qu’une partition ne peut être montée : il s’agit de notre partition efi qui a été recréée et dont l’UUID a changé. On passe outre en tapant S une nouvelle fois: la commande blkid va nous donner l’UUID de la nouvelle partition :

essai@essai-virtual-machine ~ $ blkid
/dev/sda1: UUID="906f0d8c-fdf1-4272-8b48-61ce861a5e02" TYPE="ext4" 
/dev/sda2: UUID="cd4d632a-e2d8-4a09-bfff-be24a86c5fc4" TYPE="ext4" 
/dev/sda3: UUID="48DA70FA3FA92B42" TYPE="ntfs" 
/dev/sda4: UUID="54E19840028C0E15" TYPE="ntfs" 
/dev/sda5: UUID="a9193ae0-cd72-4a4a-9ad5-7886916f0b06" TYPE="ext4" 
/dev/sda6: UUID="FF4B-2CC3" TYPE="vfat" 
/dev/sr0: LABEL="ISOIMAGE" TYPE="iso9660" 
essai@essai-virtual-machine ~ $

On édite le fichier fstab pour le modifier via la commande sudo gedit /etc/fstab . Il ne reste plus qu’à remplacer l’UUID erronée par la nouvelle.

Notre Linux va fonctionner dorénavant tout à fait normalement. Le résultat final :

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 :

1. La réparation réussie. Élimination de l’inutile.
2. La réparation échouée et Ubuntu réparé via supergrub2disk.
3. 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.

 

 

Ce problème est souvent lié à des PC initialement préinstallés en UEFI dont le disque dur en gpt a été formaté pour le passer en mbr (ms-dos), et ce très souvent pour y installer Windows 7 en Legacy.

L’erreur de beaucoup d’utilisateurs est de croire qu’un formatage convertit un disque gpt en mbr. Or, il n’en est rien.

1. Etat du problème : une table de partition corrompue.

L’installateur d’Ubuntu peut renvoyer ceci lorsqu’on veut installer cette distribution :

Le disque semble vide, alors qu’un W7 est déjà installé sur le disque. Le retour des deux commandes suivantes va nous donner des précisions:

sudo parted -l
sudo fdisk -l

Résultat commande: sudo parted -l

Résultat commande: sudo fdisk -l

On constate que le disque présente bel et bien une table ms-dos, mais que parted et fdisk décèlent des traces de format gpt. Le formatage n’a pas suffi à les supprimer.

2. La réparation de la table de partitions.

Le meilleur outil  permettant de régler le problème sans formatage est gdisk. Il est capable de « zapper » les traces de gpt. Le lien suivant présente le tout en images. Donc, inutile de dupliquer ce qui existe déjà.

http://www.linuxbsdos.com/2013/02/26/zap-gpt-data-structures-from-a-disk-while-preserving-existing-mbr-partitions/

Je résume: on connecte son live-cd ubuntu à Internet. On installe gdisk:

sudo apt-get install gdisk

Et on le lance (on adapte sdX au disque concerné, soit sda, sdb, sdc, etc).

sudo gdisk /dev/sdX

Il va  proposer 3 options:

• On choisit l’option 1-mbr .
• Pour info, la touche « ? » montre toutes les options disponibles de gdisk.

Remarque: comme le dit jamesbad000 (qui traduit les propos du concepteur, Rod Smith), l’opération n’est pas 100 % sans risque. Dans de rares cas, l’opération peut générer des problèmes de chevauchement. Donc, je  donne deux conseils :

1. Faire une copie de tes données sous W7 au préalable.
2. Dans gdisk, on utilise d’abord l’option « b«  pour faire une sauvegarde de la table de partitions actuelle. On l’appelle mbr_initial (par_exemple). On récupère le fichier dans /home du live-cd et on le sauve sur usb ou en fichier joint dans un mail. On aura ainsi une bouée de sauvetage en cas de problème.

Une fois la table de partitions sauvée, on va débarrasser le disque de ses résidus du format gpt.

• On choisit « x » pour avoir des options avancées, puis « z » pour zapper les traces de gpt.
• Ensuite, gdisk va proposer « about to wipe gpt« , on répond  « y » . On ferme gdisk et on redémarre le pc.

Attention !!! quand on nous  propose ensuite « blank out mbr ». On répond obligatoirement « n » (sinon, il efface tout le disque).

Le résultat après redémarrage :

L’installation se fera désormais sans problème. Le disque a retrouvé une table de partitions ms-dos propre. On peut installer son Linux sans difficulté.

(Ce tuto est devenu banal, mais je le conserve pour l’exemple)

Comme W10 preview vient de sortir, pourquoi ne pas tester la bête ? Et tant qu’à faire, autant y aller en dual-boot sur disque gpt avec W8 et en uefi. Le mode Legacy/mbr étant appelé à disparaître, les deux ou trois tutos qui existent déjà n’ont que peu d’intérêt, à moins qu’on veuille un XP /W10 ou W7/W10. Mais les derniers W7 étant déjà installés en uefi, autant rester dans l’actualité.
Comme j’ai lu quelque part que son installation rendait inopérant le recovery de W8, je procède prudemment et je fais l’installation sous Vmware, histoire de voir ce qu’il se passe. Selon moi, si on fait bien les choses, on ne doit pas perdre son recovery si on garde W8.
La situation de départ est la suivante:

On est bien en UEFI. et le disque est bien au format gpt.. j’ai 25 Go de place, et j’ai poussé la ram de mon PC virtuel à 2 Go.

1. Tentons une installation de W10 depuis W8 lui-même

(ça fonctionne bien avec W7, pourquoi pas W10 ?). Ca se lance sans problème

Jusqu’à ce qu’on arrive ici:

Là, j’abandonne, car visiblement, il veut virer mon W8 virtuel (j’y tiens un peu quand même)… le mieux qu’il propose est de conserver mes fichiers… je m’en fiche, je n’en ai pas. Donc, on va l’installer en bootant (il est vrai que je n’ai pas formaté la partition à l’avance, et ceci explique peut-être cela… je referai un essai une autre fois.).

2. Installation en uefi, depuis le boot

Le démarrage sur DVD se fait bien, ça commence comme W8… me serais-je planté ?

Eh non, on est bien sur un truc british.

Je change tout de même le clavier pour passer en français… la suite est classique.

 

L’installateur voit bien mes partitions, donc je lance l’installation sur l’espace libre. Tout semble rouler, même si c’est un peu longuet.
Là, gros stress…. reboot et pas de menu dual-boot…

Longue page d’accueil, écran noir durant 2 à 3 minutes…. ouf, une page en anglais reparaît….

Je m’efforce de « getting ready » (à nouveau un moment assez long… plusieurs minutes. Mais étant sur Vmware, il faut être patient)… Et en effet.

On me propose des options par défaut ou une installation perso.

Je prends perso et je refuse quasiment tout… Là, on me demande un compte hotmail, heureusement, j’en ai un qui traîne… Pas moyen de contourner ce passage obligé (comme c’est une preview, on peut comprendre). Il me propose de m’envoyer un code… je refuse tout en bloc… ça semble passer.

L’écran passe pas toutes les couleurs de l’arc-en-ciel…

Et au final, on y est…. un Windows somme toute banal…

Le dual boot est bel et bien correctement géré en uefi par W10…

 

3. Petit complément intéressant.

 

Pour dépanner ceux qui galèrent pour installer Ubuntu en dual boot avec W8/W10 préinstallé en uefi (et pour faire taire ceux qui racontent n’importe quoi… et j’en connais), je propose un tuto en images.

La procédure a été réalisée sur un pc virtuel sous vmware (avec virtualbox, j’ai eu des problèmes avec l’uefi trop instable). J’ai choisi Xubuntu plutôt qu’Ubuntu pour une question de compatibilité graphique. Et je n’aime pas Unity.

1. Situation de départ: W8 installé en uefi.

Je ne détaille pas l’installation de W8, celui-ci étant en principe déjà en place sur les pc.

Le pc présente ici trois partitions au départ.

• Récupération de 300 Mo: c’est le démarrage avancé (console de réparation).
• Partition efi de 99 Mo: partition de démarrage (elle contient les fichiers efi)
• Partition C en NTFS: le système.

Un diskpart montre qu’une partition « réservé » est cachée: msr de 128 Mo

Les trois premières partitions ne doivent absolument pas être modifiées. Les pc du commerce possèdent en outre une partition recovery qu’il faut bien entendu ne pas modifier si on veut ne pas perdre la possibilité de restaurer en interne.

2. Les opérations de sauvegarde.

A ce stade, puisqu’on va faire des modifications, il est plus que judicieux de faire des sauvegardes de sécurité.

- Création de la clé de récupération selon la méthode préconisée par le constructeur. Attention, bugué chez Asus et Acer.
- Création d’une image du disque complet avec Acronis, Aomei ou autre.
- Sauvegarde de la partition efi (facultatif). On peut la monter avec la commande mountvol z: /s et accéder aux fichiers efi.

3. Préparation de l’emplacement de Xubuntu

On réduit la partition C de Windows depuis W8 directement (touche windows + X et gestion de disque). On évite les outils tiers qui génèrent des problèmes, gparted y compris. Ici la partition de 30 go est réduite à 18 Go, ce qui laisse largement la place pour installer xubuntu.

Le résultat est le suivant, lorsque l’opération est finalisée. On est prêt à lancer l’installation de notre Linux.

4. Démarrer son Xubuntu en Uefi

A ce stade, c’est la configuration du bios/uefi qui va déterminer comment on s’y prend. En principe, le bios est réglé en uefi et le DVD d’ubuntu doit se lancer automatiquement dans ce mode (si besoin, le mettre en tête de liste dans le boot). Si on n’est pas sûr, on désactive l’option legacy, l’option csm, on active « other systems » et si nécessaire, on désactive « le boot secure » (en principe, c’est inutile, la signature d’ubuntu étant connue de W8).

Sur Vmware, les choses sont simples et via F2, on accède à un menu boot qui permet de lancer le DVD en uefi.

Sur un vrai pc, on trouve parfois l’équivalent via une touche Fxx ou via l’onglet « boot avancé » dans le bios/uefi… Là, je ne peux pas donner toutes les options, tant les bios/uefi sont nombreux et différents. Il faut un peu chercher. On arrive à quelque chose ressemblant à ceci.

On lance le DVD ou l’USB  Xubuntu en mode uefi. C’est ici qu’une première vérification doit être faite. Le menu Grub qui s’affiche doit présenter un fond noir, et non un fond violet.

Edit. Les distributions Linux étant signées, on ne désactive plus le boot-secure. On s’assure simplement que le live-cd démarre sur le menu en noir et blanc de Grub.

On accède au grub de Xubuntu, et on choisit d’essayer (et non d’installer), car ça permet de voir si le pc supporte bien Xubuntu (Wifi, graphisme, pavé tactile, etc.)

Xubuntu se lance et on accède au bureau du live-cd. On choisit d’installer.

5. L’installation

Il suffit de maîtriser très vaguement l’anglais pour trouver l’icône d’installation sur le bureau.

La suite est sans surprise, passage en français, etc. jusqu’à ce menu.

Ici, il faut être prudent. Un bug depuis la version 13.04 masque la présence de W8 à l’installateur…  (obsolète depuis la version 16.04).

Il faut absolument choisir l’option « autre chose » (Edit. Ce n’est plus une obligation, mais je conseille cette option, qui permet de savoir ce qu’on fait). On va partitionner manuellement. Sur l’espace libre, on choisit de créer (avec la touche +)

- une partition ext4 de 10 Go avec le marqueur / comme point de montage pour mon Linux (qui devient sda5)
- une partition swap avec ce qu’il me reste. Ici 2 Go, ce qui correspond à ma ram.
- (on aurait pu créer un /home indépendant, mais pour mon exemple, ça n’avait pas grand sens).

En bas de page, on laisse le programme de démarrage (grub2.efi, en réalité) s’installer où il le veut, par défaut. On lance l’installation qui se fait en 15 min environ. C’est de plus en plus rapide.

Une fois que c’est terminé, il suffit de redémarrer pour voir que grub s’est correctement mis en place et a bien identifié W8 qu’il lance depuis la partition sda2, c’est-à-dire la partition efi.

6. Le dual-boot

Les deux systèmes fonctionnent. Tout fonctionne parfaitement. On peut d’ailleurs vérifier le contenu de la partition efi en montant la partition via la commande mount. (Edit. Pas nécessaire, puisque la partition est montée via le fichier fstab)

Le dossier efi/boot contient bien le fichier bootx64.efi nécessaire au démarrage.
Le dossier efi/ubuntu avec les fichiers efi nécessaires à grub a bien été ajouté.
Les dossier efi/microsoft contient les copies des fichiers originaux du démarrage de W8.

7. Quelques remarques utiles.

- La partition W8 peut être inaccessible si l’option « démarrage rapide » est activée. En effet, dans ce cas, W8 est simplement mis en veille et le montage de partition échoue (puisqu’elle est « occupée »). Il faut donc désactiver obligatoirement cette option si on veut y accéder. Si on « force » le montage avec la commande mount (ce que j’ai tenté), W8 marquera une erreur au démarrage suivant et proposera une réparation de la partition… mais dans le doute, mieux vaut être prudent.

- On peut toujours modifier l’ordre de boot selon la méthode traditionnelle ( /etc/default/grub et les fichiers du dossier /etc/grub.d), proposée sur le site ubuntu. Là, il n’y a pas de changement par rapport à l’installation en mbr.

- On peut supprimer le dual-boot (si on ne veut plus de son Linux) en utilisant le DVD ou la console W8 via la commande bcdboot c:\windows (c: est peut-être à adapter). W8 redémarre seul et on peut supprimer les partitions Linux.

(il ne me reste plus qu’à « torturer » tout ça avec gdisk, testdisk, boot-repair, bootrec /fixmbr pour voir comment on peut sauver une situation désespérée…. à suivre).

8. Réparations possibles

a) Réparer la partition efi complètement

Pour réparer tout ça… J’ai utilisé un une clé usb W7 64 bits non modifiée, c’est-à-dire sans le dossier efi/boot/bootx64.efi (l’équivalent avec W8 ou les clés de réparation fonctionnent aussi). J’ai écarté l’utilisation de gparted, et je testerai plus tard gdisk afin de voir si le fait de mettre le code EF00 sur une partition fat32 avec drapeau boot suffirait.

a1. On recrée la partition efi

diskpart 
select disk n (n étant le numéro du disque dur).
create partition efi
format fs=fat32
exit

Rien de plus, le gestionnaire de partitionnement fait tout le travail en choisissant l’espace libre et en attribuant le statut système

a2. On réécrit son contenu.

Microsoft a fait les choses plutôt correctement avec la commande bcdboot qui va chercher les fichiers dans la partition Windows pour les écrire sur la partition système

bcdboot c:\windows (c, d, ou e... un list volume permet de savoir)

A ce stade, on peut constater que notre W8 est réparé et redémarre.

a3. On répare grub pour récupérer ubuntu. Pour ça, on utilise le live-cd Linux.

Réparation automatique avec boot-repair… les fichiers de grub sont réécrits, mais boot-repair ajoute pas mal d’entrées inutiles qui polluent un peu le démarrage. On est cependant obligé de passer par là si on n’a pas une console de W7 ou de W8.

Pour réinstaller manuellement les fichiers grub dans la partition efi. Utile pour le cas où on n’a pas fait de sauvegarde.

Je me suis inspiré de ce site :

http://superuser.com/questions/376470/how-to-reinstall-grub2-efi

sudo mount /dev/sda5 /mnt #sda5 est ma partition Linux
sudo mount /dev/sda2 /mnt/boot/efi #sda2 est ma partition efi
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done  (on monte tout ce qui est nécessaire pour chrooter)
sudo cp /etc/resolv.conf /mnt/etc/ #active le réseau après le chroot
modprobe efivars # efivars semble nécessaire au bon fonctionnement du chroot
sudo chroot /mnt

Ici, les commandes proposées sur le lien fonctionnent mais n’écrivent rien dans le dossier boot/efi (j’ai vérifié). J’ai remplacé par un simple

grub-install
sudo update-grub

Le dossier ubuntu et ses quatre fichiers sont ajoutés. On n’a plus qu’à démonter le tout pour finir le travail proprement…

Ctrl+D pour sortir du chroot

for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
sudo umount /mnt/boot/efi
sudo umount /mnt 
sudo reboot

On retrouve son dual boot W8/Ubuntu opérationnel et parfaitement propre.

(Le tuto est un peu ancien… d’où des images un peu petites)

N’ayant pas trouvé grand chose de concret (ni personne) pour expliquer l’installation d’un dual-boot W8 / Fedora, je me fends d’un tuto, qui permettra de visualiser la démarche.

Il existe déjà ce tutoriel vidéo, mais il a le tort de créer deux partitions efi, ce qui génère un message d’erreur au redémarrage de W8, et cela conduit à une réparation longue et compliquée qui n’est pas à la portée de l’utilisateur lambda . Je le propose tout de même, pour information:

https://www.youtube.com/watch?v=xzUKCApxfRw

1. Le boot sur le DVD

C’est souvent le premier gros problème. Certains bios sont bloqués, d’autres sont à paramétrer. A ce sujet, il faut simplement faire des recherches selon le modèle de pc qu’on possède, mais en principe, Fedora possédant une signature reconnue, on ne devrait rien modifier, ou dans le pire des cas, l’ordre de démarrage.

2. Préparation du disque.

On la réalise depuis W8 lui-même, comme expliqué ici dans le tuto W8 /ubuntu: points 1 à 4.

http://www.commentcamarche.net/forum/affich-30036914-dual-boot-w8-xubuntu-13-10-en-uefi-tutoriel

Je me contente donc de présenter la situation de départ :

Je suis bel et bien en uefi (les partitions le montrent), et je vais utiliser l’espace libre de 11,72 Go, ce qui suffira pour la démonstration.

3. Le live-cd

On démarre sur le live-cd qui lance directement Fedora. Il est également possible de lancer le live-cd en redémarrant son W8 en mode avancé, puis en choisissant de démarrer sur un périphérique. C’est comme on veut. Fedora s’arrête sur ce choix :

Le plus sage est de choisir l’option « Try Fedora » afin de vérifier que tout est compatible (wifi, carte graphique…). L’inconvénient est que le clavier est en qwerty… si on veut basculer en azerty, on tape dans un terminal setxkbmap fr. Par prudence, je vérifie par un parted -l que mes partitions sont bien celles qu’a vues W8 :

 

4. Le début d’installation

Tout étant bon, on lance l’installation, en cliquant sur l’avant-dernière vignette du menu de gauche… je passe sur la mise en français qui se fait toute seule. Tout fonctionne comme dans le tuto vidéo, et donc on arrive ici:

 

5. Le partitionnement

On sélectionne alors l’option « installation destination ». N’ayant qu’un seul disque sur mon pc virtuel, il m’est proposé. J’accepte en cliquant sur « terminé » :

Une nouvelle fenêtre s’ouvre. Je modifie les options comme suit:

 

Le partitionneur de Fedora me propose alors un état de ma situation actuelle. W8 est jugé « inconnu » mais mes partitions sont présentes. J’ai 12 Go de libres, la possibilité d’ajouter des partitions, et aussi de modifier l’état actuel d’une partition avec le symbole >

 

Contrairement au tuto vidéo, je renonce au partitionnement automatique (car il duplique à tort la partition efi) et je vais créer mes partitions moi-même. Je commence par faire comprendre à Fedora que je veux utiliser la partition efi actuelle. Je clique sur > ce qui « dégrise » la ligne « point de montage ». Elle me suffit. J’ajoute simplement /boot/efi dans cette ligne. Je valide par « mise à jour des paramètres » pour que la modification soit prise en compte. Maintenant, Fedora sait qu’il va devoir installer grub sur cette partition.

Avec la touche + j’ajoute mes partitions Linux. J’ai choisi d’en créer 3:

• Une partition / pour le système (6 Go me suffisent pour la démo)
• Une partition /home pour les données (5 go sont suffisants)
• Une partition swap (pour les échanges).

Le résultat est le suivant :

 

A noter que ma partition efi (sda2) apparaît deux fois: donc elle est commune à l’installation Fedora et à mon « inconnu » W8. Il ne reste qu’à valider par terminer. Une demande de confirmation est proposée. On se lance.

L’erreur suivante est survenue dans mon cas (comme dans le tuto vidéo)…

 

Sur la vidéo, elle s’est corrigée d’elle-même. Moi, j’ai simplement fait une vérification de mes partitions (qui étaient correctes), et l’erreur s’est corrigée spontanément. J’ai sans doute manqué de patience. Et là, on lance l’installation… A la fin, il ne reste plus qu’à redémarrer. Un menu grub est proposé.

 

Fedora se lance sans erreur ; idem pour W8 :

 

6. Procédure pour réparer Grub depuis Fedora

procédure pour réinstaller grub2 en uefi sur fedora depuis le live-cd.

On passe en root:

su -

On monte les partitions systèmes (on remplace X  et Y par le numéro de partition) :

mount /dev/sdaX /mnt # exemple, sda5 pour la partition Linux
mount /dev/sdaY /mnt/boot/efi # exemple, sda2 est la partition efi

On monte les outils nécessaires à la réinstallation.

mount --b /dev /mnt/dev    
mount --b /dev/pts /mnt/dev/pts  
mount --b /sys /mnt/sys   
mount --b /proc /mnt/proc

On chroote:

chroot /mnt

On installe tous les outils pour grub-efi:

yum install grub2-efi grub2-efi-modules shim

On peut vérifier par

ls /boot/efi/EFI

qu’un dossier fedora s’est bien ajouté, puis avec

ls /boot/efi/EFI/fedora

qu’il contient les fichiers habituels. On actualise grub :

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Là, on peut vérifier que grub.cfg s’est bien ajouté:

ls /boot/efi/EFI/fedora

On vérifie que W8 est bien détecté (chez moi, ce n’était pas le cas). Donc, j’ai modifié à la main le fichier grub.cfg (il serait plus pertinent de modifier 40_custom, mais j’ai été fainéant sur ce coup:

vi /boot/efi/EFI/fedora/grub.cfg

J’ai ajouté l’entrée suivante dans la zone 30_os-prober

menuentry "Windows Boot Manager" {
chainloader /EFI/MIcrosoft/boot/bootmgfw.efi
}

Un blkid pour vérifier l’uuid de la partition efi, si besoin, on modifie fstab comme indiqué plus haut (exemple

vi /mnt/etc/fstab

)
On quitte le mode chroot par ctrl D.
Puis on démonte ce qui a été monté par umount (ex

umount /mnt/proc

Un tuto d’installation de Fedora en Legacy :

http://lea-linux.org/documentations/Installer_Fedora_24

 

Un petit truc pour réactiver le lancement d’Ubuntu après qu’une mise à jour de Windows 8 a redonné la main à W8 (dans ces cas-là, l’entrée ubuntu n’est plus proposée).

Ceci s’applique en particulier lorsque le bios (plombé sur certains pc) n’offre pas d’option pour relancer UUbuntu directement:

Inspiré de http://forum.ubuntu-fr.org/viewtopic.php?pid=15030301#p15030301

1. On relance Ubuntu en passant par le démarrage avancé, comme indiqué sur le lien précédent. Le pc va redémarrer sur ubuntu, une seule fois. Ça nous suffira.

2. On accède alors à Ubuntu, ce qui va nous permettre quelques manipulations.

3. On lance un terminal et on tape la commande:

sudo efibootmgr

La commande affiche l’ordre de boot actuel du pc.

BootOrder: 0000,0005,0001,0002,0003,0004
Boot0000* Windows Boot Manager
Boot0001* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0002* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0003* EFI Network
Boot0004* EFI Internal Shell (Unsupported option)
Boot0005* ubuntu

On constate que la mise à jour a placé Windows boot manager (0000) devant Ubuntu (0005), et donc ubuntu (grub) ne peut plus se lancer . Ici, le tuto du forum propose de taper la commande sudo grub-install (ce qui doit bien entendu fonctionner) .

Un autre moyen est possible (sans réinstaller grub, et surtout nettement plus personnalisable), à savoir:

sudo efibootmgr -o 0005,0000,0001,0002,0003,0004

On reprend simplement l’ordre de boot en rectifiant l’ordre initial par celui qu’on souhaite (ici, j’inverse 0000 et 00005). On valide et le tour est joué. On vérifie :

sudo efibootmgr

Le résultat est

BootOrder: 0005,0000,0001,0002,0003,0004
Boot0000* Windows Boot Manager
Boot0001* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0002* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot0003* EFI Network
Boot0004* EFI Internal Shell (Unsupported option)
Boot0005* ubuntu

Le dual-boot est réparé.

Recréation manuelle de la partition WinRE en UEFI

Microsoft documente la création de cette partition winre… via la commande diskpart (en administrateur)

1. Création de la partition

create partition primary 
format quick fs=ntfs label="Récupération"
assign letter="T"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001

(on crée la partition au format souhaité pour winre sur disque gpt)

2. On désactive l »actuel winre ».

reagentc.exe /disable

3. Ensuite, il faut copier les fichiers nécessaires sur cette partition.

La commande suivante doit en principe fonctionner (je reprends les préconisations Ms):

robocopy.exe C:\windows\system32\recovery\ T:\recovery\windowsRE\winre.wim /copyall /dcopy:t

4. Redirection  vers la bonne partition et le bon dossier

 reagentc /setreimage /path t:\recovery\windowsRE\winre.wim

5. Réactivation de winre

 reagentc /enable

6. On supprime la lettre assignée à la partition recovery

diskpart
remove letter="T"
exit

7. Ajouts (problèmes possibles)

Il se peut que la commande suivante aboutisse à un message d’erreur.

reagentc /disable
reagentc.exe opération échouée: 2

La même tentative avec /enable aboutit à l’erreur 57. Dès lors, la suite est systématiquement refusée. Microsoft propose un hotfix qui ne fonctionne pas. La situation semble bloquée.

Heureusement, un certain Tiger01 (droits d’auteur obligent) propose le remède et l’explication. C’est le lien vers la partition supprimée qui ne fonctionne plus, et le système se redirige spontanément vers c:\recovery qui peut ne pas exister ou qui peut être endommagé. Dans mon cas, il était présent, mais endommagé. J’ai donc renommé le dossier initial en recovery.old, puis exécuté les opérations suivantes :

reagentc /info

La commande renvoie une série d’informations, dont l’identificateur de la base bcd (quelque chose comme 5c6030e1-2ec0-41e4-bece-e1af3e345dc8 (on copie cet id ).
On crée un nouveau dossier nommé Recovery, et à l’intérieur, un second dossier avec l’id en question :

Recovery
      |
      |____ 5c6030e1-2ec0-41e4-bece-e1af3e345dc8

Dans ce dossier, on copie le fichier winre.wim depuis c:\windows\system32\recovery
Idem pour le fichier boot.sdi depuis c:\windows\system32

On redémarre un coup, et on reprend la procédure qui cette fois, ne pose plus aucun problème. On peut carrément supprimer le dossier recovery qu’on a créé temporairement, car il ne sert plus à rien.

http://social.technet.microsoft.com/Forums/windows/en-US/b059a404-d00b-4273-8c84-df0139e09ad6/reagentc-operation-failed-2?forum=w7itproinstall

1. Situation de départ

Partons de l’idée qu’ayant acheté un W8 ou W10 flambant neuf, je sois, comme beaucoup, immédiatement nostalgique de W7. Je pars de cette situation (un W8 ou 10 propre, en uefi, disque au format gpt):

Sans me poser de question, je tente une installation directe, mais mon DVD W7 ne boote pas. Google étant mon ami, je me mets en quête d’une réponse au problème.

Quelques recherches plus tard, je tombe sur un tuto (ou sujet noté + 95, c’est cool) expliquant que le problème vient de l’UEFI et qui m’indique que je dois installer mon W7 en mode legacy (bios classique). Bon, ça a l’air simple…

Résumons. On me dit de passer formater mon disque dur avec diskpart ou gparted, de le convertir avec clean, et de passer mon PC en legacy. Ok, allons-y. Je suis kamikaze.

Je fais ça ici en invite de commandes, mais d’autres utilisent gparted ou équivalent… Ça n’a pas d’importance, mes intentions suicidaires ne dépendant pas de l’arme choisie.

J’ai donc tout supprimé, et converti en mode mbr. Je suis prêt à installer W7.

Et là, surprise. Mon W7 ne boote toujours pas, ou pire, mon bios est bloqué en UEFI et il m’est impossible d’installer quoi que ce soit. Et n’étant pas prévoyant, je n’ai fait aucune sauvegarde. En principe, c’est là qu’on poste un « mayday » sur les forums.

2. Etat des lieux.

Je télécharge une version Linux récente (ici, Mint 17 64 bits option xfce). Le but étant de réparer, autant avoir un bureau simple et assez léger.

http://www.linuxmint.com/download.php

Après gravure du cd ou création d’une usb bootable avec Lili, je peux faire booter mon cd et constater l’étendue des dégâts (ça boote en uefi, même avec le boot-secure. Sinon, au pire, je le désactive dans le bios):

Eh oui, tout est vide… et le disque est bien passé en mbr (= ms-dos). Eh bien, c’est la tuile. Comment réparer tout ça ?

3. Récupération des partitions.

Testdisk est un utilitaire permettant de récupérer les partitions perdues. Essayons. D’abord, on l’installe, puis on l’exécute… avec un terminal (= invite de commande).

Je suis les indications du programmes : no-log – je choisis le mode « intel » – mon disque dur – analyse ne trouve rien – quick search. Ah mes partitions perdues sont là. Par chance, il gère bien le mode mbr.

Je vois par la petite * que testdisk se prépare à réinstaller mes partitions pour une installation en mbr… Moi, je veux du gpt. Je vais donc modifier les choses pour ne rien rendre bootable, et ne récupérer que l’essentiel (W8, le recovery, la partition constructeur). N’oublions pas qu’en mbr, je suis limité à 4 partitions. Je vais modifier les choses avec les flèches gauche et droite. Donc, je récupère la première, Winre en attribuant P (et encore, je pourrai la refaire plus tard), je zappe la partition fat32 (ex-efi), je prend bien sûr mon Windows (P) et mon Recovery d’usine (ici, c’est en fait un Linux en partition logique, d’où le L). Ce qui donne ceci :

Un write et un redémarrage plus tard sur le live-cd de Mint, on en est là :

Déjà, mes partitions sont lisibles, et mes données récupérables. Mais mon disque dur est en mode md-dos, et non en gpt. En principe, on doit formater pour reconvertir. Donc, toujours impossible de booter. On va utiliser le génial gdisk pour combler l’espace libre de 227 Mib, ce qui va convertir le disque sans rien supprimer.

4. Conversion du disque dur de mbr à gpt avec gdisk.

D’abord, on installe le programme; rien de plus simple :

On le lance en lui associant le disque à modifier, ici, /dev/sda.

Maintenant, il faut recréer une partition efi et une partition msr. Sachant que msr doit faire 128 Mib, je vais limiter mon efi à 227-128 = 99 Mib. Le code efi est ef00; le code msr est 0c01. Allons-y :

La commande « n » crée la partition. D’abord efi (+99M et ef00), puis msr (0c01… la taille sera ajustée automatiquement à l’espace libre). Un « w » et un « y » plus tard. Vérifions le résultat :

Les choses se présentent bien, le disque est passé en gpt, et mes partitions sont bien là. Il me reste à réparer le démarrage de Windows qui ne peut toujours pas booter.

5. Réparation du démarrage avec dart.

Il me faut soit le DVD W8 (bien sûr je ne l’ai pas), soit Dart (un outil de dépannage Ms) :

http://forum.pcastuces.com/images_de_recuperation_dart_8_et_81-f7s963.htm

Je choisis la version W8 64 bits, et suis le tuto pour créer l’outil de dépannage. En effet, ça boote correctement en uefi. Je respecte les étapes jusqu’à l’invite de commandes. Je vérifie grâce à diskpart les lettres associées à mes disques (ici D = windows). Je vais utiliser une commande de réparation très efficace, bcdboot.

Sans extension, la commande est directement acceptée. C’est très bien. Ca doit redémarrer. Et en effet :

Mon W8 est récupéré… j’oublie définitivement mes velléités d’installation de W7.

 

Dans la série des dual-boot en UEFI, il est temps de s’intéresser à la cohabitation entre deux versions de Linux différentes. Le test est fait avec une Mint 17 installée en UEFI, à laquelle on ajoute une Fedora 20. Mais l’expérience serait exactement la même avec des versions plus récentes.

L’installation se fait selon le protocole proposé ici :

http://ikewdu.free.fr/dual-boot-windows-8-fedora-20-en-uefi/

Comme pour le dual-boot W8/Fedora du lien précédent, je choisis le partitionnement manuel pour utiliser la même partition efi que pour ma Mint en ajoutant simplement le point de montage /boot/efi à la partition efi pour que mes fichiers grub s’installent au bon endroit. Le résultat sera donc le suivant :

En rouge, la partition efi, en vert, ma Mint, et en orange, ma Fedora.

I)  Tests de démarrage après installation

1) Test de démarrage sur Fedora.

L’installation s’est bien déroulée, et on obtient bien un grub au démarrage, d’un aspect différent de mon grub initial (Fedora a pris la main). Une première exécution confirme que ma Fedora se lance tout à fait proprement.

Mais, après redémarrage, mauvaise surprise.  Les liens vers Mint aboutissent à des messages d’erreur systématiques :

On va donc essayer de redémarrer notre Linux Mint en changeant l’ordre de démarrage (soit directement dans le bios, soit par la commande efibootmgr tapée depuis Fedora). Bien évidemment, il n’est pas installé. On va donc chercher le paquet et l’ajouter.

[essai@localhost ~]$ yum search efibootmgr
Modules complémentaires chargés : langpacks, refresh-packagekit
=========================== N/S matched: efibootmgr ============================
efibootmgr.x86_64 : EFI Boot Manager
Correspondance avec le nom ou le résumé uniquement, utilisez « search all » pour une recherche complète.

[essai@localhost ~]$ yum install efibootmgr.x86_64
Modules complémentaires chargés : langpacks, refresh-packagekit
Vous devez être super-utilisateur pour exécuter cette commande.

[essai@localhost ~]$ su
Mot de passe :
[root@localhost essai]# yum install efibootmgr.x86_64
Modules complémentaires chargés : langpacks, refresh-packagekit
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet efibootmgr.x86_64 0:0.5.4-16.fc20 sera mis à jour
---> Le paquet efibootmgr.x86_64 0:0.11.0-1.fc20 sera utilisé
--> Traitement de la dépendance : efivar-libs >= 0.8 pour le paquet : efibootmgr-0.11.0-1.fc20.x86_64

(on saute quelques lignes)
Mis à jour : efibootmgr.x86_64 0:0.11.0-1.fc20
Terminé !

Après tout ce processus, on aboutit enfin à notre commande :

[root@localhost essai]# efibootmgr -v
BootCurrent: 0005
BootOrder: 0005,0004,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)SATA(1,0,0)
Boot0002* EFI Network    ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(MAC(000c29b06483,0)
Boot0003* EFI Internal Shell (Unsupported option)    MM(b,3efcb000,3f355fff)FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0004* ubuntu    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\EFI\ubuntu\shimx64.efi)
Boot0005* Fedora    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\EFI\fedora\shim.efi)

On voit que c’est Fedora qui a la main sur le démarrage. On va modifier l’ordre pour repasser le grub de Mint en tête de cette manière :

[root@localhost essai]# efibootmgr -o 0004,0005,0000,0001,0002,0003
BootCurrent: 0005
BootOrder: 0004,0005,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* ubuntu
Boot0005* Fedora
[root@localhost essai]# ^C
[root@localhost essai]#

C’est bon, on devrait démarrer sur notre Mint. C’est bien le cas.

2) Test de démarrage sur Ubuntu/Mint

On reconnaît effectivement notre grub Ubuntu, mais on n’a pas d’option pour faire démarrer notre nouvelle distribution Fedora. C’est gênant :

Le plus simple va être de démarrer notre distribution Mint pour régler ça. On va essayer d’ajouter l’entrée Fedora grâce à la commande sudo update-grub. On verra bien si l’entrée s’ajoute.

essai@essai-virtual-machine ~ $ sudo update-grub
[sudo] password for essai: 
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
Fedora release 20 (Heisenbug) trouvé sur /dev/sda5
fait
essai@essai-virtual-machine ~ $

Tout va bien. On va en profiter pour lancer un petit boot-info pour regarder comment se présentent les choses.

boot-info-depart

On constate deux ou trois choses notables :

On a bien sur sda1 (la partition efi) des fichiers Ubuntu et des fichiers Fedora.

sda1: Boot sector type:  Windows 8/2012: FAT32

Boot files:        /EFI/BOOT/fallback.efi /EFI/fedora/MokManager.efi
/EFI/fedora/gcdx64.efi /EFI/fedora/grubx64.efi
/EFI/fedora/shim-fedora.efi /EFI/fedora/shim.efi
/EFI/ubuntu/MokManager.efi /EFI/ubuntu/grubx64.efi
/EFI/ubuntu/shimx64.efi

On trouve bien un fichier grub.cfg, mais aucun sur sda5 (où est-il ?). Donc, boot-info ne peut lire qu’un des fichiers de démarrage, celui de sda3.

sda3: File system:       ext4
Operating System:  Ubuntu 14.04 LTS
Boot files:        /boot/grub/grub.cfg /etc/fstab
/boot/grub/i386-pc/core.img

sda5: File system:       ext4
Operating System:  Fedora 20 (Heisenbug)
Boot files:        /etc/fstab

Notre commande efibootmgr a bien été enregistrée.

=================== efibootmgr -v
BootCurrent: 0004
BootOrder: 0004,0005,0000,0001,0002,0003
Boot0004* ubuntu    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(EFIubuntushimx64.efi)
Boot0005* Fedora    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(EFIfedorashim.efi)

Nous allons donc redémarrer pour voir si notre Fedora se lance correctement.

Visiblement, c’est bon…  Essayons.

Fedora se lance. Mais le joli démarrage graphique de la distribution Fedora est passé à la trappe, pour laisser place à des codes un peu indigestes.

==> Bilan : les deux démarrages sont à réparer.

3) Réparation du démarrage depuis Mint (remise des options vidéo de Fedora).

Puisqu’on y est, autant commencer par ça On redémarre sur notre Mint et on va se mettre en quête du fameux fichier grub.cfg de Mint. En fouillant un peu, on le trouve dans /boot/efi/efi/fedora

Nous allons donc l’éditer pour observer son contenu:

grub.cfg-fedora

On constate que la section 10_Linux contient tout le démarrage en mode graphique de Fedora. Comparons avec notre section 30_os-prober présente dans le boot-info (en vert, la vidéo, en gris la condition inutile, en bleu le démarrage):

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Fedora release 20 (Heisenbug) (sur /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-8b848441-3bbd-401e-8151-d2b779b294bf' {
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  8b848441-3bbd-401e-8151-d2b779b294bf
else
search --no-floppy --fs-uuid --set=root 8b848441-3bbd-401e-8151-d2b779b294bf
fi
linux /boot/vmlinuz-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543 root=/dev/sda5
initrd /boot/initramfs-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543.img
}
submenu 'Options avancées pour Fedora release 20 (Heisenbug) (sur /dev/sda5)' $menuentry_id_option 'osprober-gnulinux-advanced-8b848441-3bbd-401e-8151-d2b779b294bf' {
menuentry 'Fedora release 20 (Heisenbug) (sur /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543--8b848441-3bbd-401e-8151-d2b779b294bf' {
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  8b848441-3bbd-401e-8151-d2b779b294bf
else
search --no-floppy --fs-uuid --set=root 8b848441-3bbd-401e-8151-d2b779b294bf
fi
linux /boot/vmlinuz-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543 root=/dev/sda5
initrd /boot/initramfs-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543.img
}
menuentry 'Fedora release 20 (Heisenbug) (sur /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.11.10-301.fc20.x86_64--8b848441-3bbd-401e-8151-d2b779b294bf' {
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  8b848441-3bbd-401e-8151-d2b779b294bf
else
search --no-floppy --fs-uuid --set=root 8b848441-3bbd-401e-8151-d2b779b294bf
fi
linux /boot/vmlinuz-3.11.10-301.fc20.x86_64 root=/dev/sda5
initrd /boot/initramfs-3.11.10-301.fc20.x86_64.img
}
}

set timeout_style=menu
if [ "${timeout}" = 0 ]; then
set timeout=10
fi
### END /etc/grub.d/30_os-prober ###

Les instructions vidéos sont différentes, de même que les commandes linux et initrd. On va donc éditer le fichier 40_custom pour le modifier et y copier les instructions de la zone 30_os-prober du fichier grub.cfg de Fedora, en modifiant quelques lignes.

sudo gedit /etc/grub.d/40_custom

On y copie les lignes qui nous intéressent… J’en profite pour supprimer les « if…fi » et l’extension efi sur linuxefi et initrdefi (on aurait pu les laisser, grub de Mint accepte ces commandes). Le résultat avec les nouvelles commandes vidéo et les conditions en moins.

Le résultat est le suivant : 40_custom

On continue en désactivant l’exécution de 30_os-prober et on finalise par un sudo update-grub.

essai@essai-virtual-machine ~ $ sudo chmod -x /etc/grub.d/30_os-prober
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
fait
essai@essai-virtual-machine ~ $

Il ne reste qu’à essayer.

Fedora nous propose bien son démarrage graphique. Notre démarrage depuis Mint est opérationnel. On va maintenant réparer notre démarrage depuis Fedora.

4. Réparation du démarrage de Fedora (suppression de l’erreur vers Mint).

On aurait pu s’arrêter là, mais l’idée de savoir que Fedora est incapable de lancer Mint est un peu gênant. Pour simplifier les choses, on va se connecter en root (administrateur) plutôt qu’en simple utilisateur (Fedora offre cette option directement au moment de la connexion du Login / MP).

On va faire la même manipulation : aller chercher dans le fichier grub.cfg dans /boot/efi/efi/fedora/grub.cfg  la zone 30_os-prober copier son contenu dans le fichier 40_custom présent dans /etc/grub.d/

(comme on est en mode root, tout peut se faire cette fois en mode graphique, par copier-coller ).

Il faudra ajouter à chaque commande linux et initrd les trois lettres efi. On supprime également la zone if… fi inutile.

J’aboutis à un fichier tel que celui-ci:  40_custom

On désative à nouveau notre 30_os-prober et on met à jour notre grub sous Fedora:

[root@localhost ~]# chmod -x /etc/grub.d/30_os-prober
[root@localhost ~]# grub2-mkconfig -o /boot/efi/efi/fedora/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.11.10-301.fc20.x86_64
Found initrd image: /boot/initramfs-3.11.10-301.fc20.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543
Found initrd image: /boot/initramfs-0-rescue-1312b1fb554f49c0b43bfa6cccf7a543.img
done
[root@localhost ~]#

Il ne reste plus qu’à tester le démarrage en redonnant la main à Fedora :

essai@localhost ~]$ su
Mot de passe :
[root@localhost essai]# 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)SATA(1,0,0)
Boot0002* EFI Network    ACPI(a0341d0,0)PCI(16,0)PCI(0,0)MAC(MAC(000c29b06483,0)
Boot0003* EFI Internal Shell (Unsupported option)    MM(b,3efcb000,3f355fff)FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0004* ubuntu    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\EFI\ubuntu\shimx64.efi)
Boot0005* Fedora    HD(1,800,2f000,08bc25da-d0fc-42f1-8df9-a694e6570d71)File(\EFI\fedora\shim.efi)

[root@localhost essai]# efibootmgr -o 0005,0004,0000,0001,0002,0003
BootCurrent: 0004
BootOrder: 0005,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* ubuntu
Boot0005* Fedora
[root@localhost essai]#

Le résultat est le suivant :

Notre dual-boot fonctionne dans les deux sens, quelle que soit la distribution qui a la main.