Archives mensuelles : septembre 2017

Créer une clé USB de dépannage Refind ou Supergrub2 Disk

Assez fréquemment, on voit des sujets sur différents forums évoquant des systèmes qui ne démarrent plus, notamment parce que la partition EFI a été bricolée ou endommagée, notamment lorsqu’on a essayé d’installer un dual-boot entre Windows et une distribution Linux.

On peut alors tenter de faire démarrer ses systèmes avec des outils de secours. En uefi, il en existent deux qui sont efficaces : Supergrub2disk, et Refind. L’un comme l’autre sont prévus pour fonctionner sur CD-Rom, mais on peut les installer sur une clé USB bootable.

Avertissement. Les PC fonctionnant en mode Legacy ne pourront pas exploiter cette procédure. Seuls les PC en UEFI sont concernés.

I) Création de la clé USB bootable.

C’est la première chose à faire. On peut la réaliser de plusieurs manières. La plus fiable est de  rendre la clé bootable sous Windows avec diskpart. On lance l’invite de commandes en admin et on tape :

diskpart
list disk (on repère le n° de la clé, d'après la taille affichée)
select disk n (on remplace n par le n° de la clé)
clean (ici, on supprime tout, donc pas d'erreur)
create partition primary
format fs=fat32 quick
assign
active (pour la rendre bootable)
exit

A ce stade, on a une clé usb bootable avec rien dessus, mais qui est potentiellement capable de booter au démarrage d’un PC UEFI.

A noter qu’il est probable que Gparted soit parfaitement capable de faire la même chose. On crée une partition fat32 sur une clé USB, et on lui adjoint le drapeau boot (je ferai l’essai à l’occasion).

II) Ajout des fichiers REFIND

On se rend sur le site du concepteur de Refind :

Il nous propose toute une série de versions de son logiciel. On ne choisira pas la version USB mais la version CD-Rom.

Cette version contient un fichier refind-cd.xx.xx.iso qu’on peut facilement «ouvrir » avec Winrar, 7zip ou avec n’importe quel gestionnaire d’archives qu’on a sous la main. Ici, j’utilise le gestionnaire d’archives par défaut de Mint 18. On va simplement extraire les dossiers encadrés directement sur la clé USB (on peut sans doute se limiter à EFI et Refind, mais je ne m’embarrasse pas).

Refind1

On peut voir dans l’image qui suit que le créateur de Refind a pris soin d’insérer le dossier EFI nécessaire au démarrage de la clé USB. On y trouve le fichier bootx64.efi, indispensable au démarrage de notre clé de dépannage.

Refind2

Il ne reste plus qu’à la tester  : on insère la clé avant de mettre le PC en route. On règle son bios-UEFI pour démarrer dans ce mode (ou on utilise le menu de démarrage du constructeur). On choisit de booter sur la clé en UEFI.

boot

Elle va détecter les installations bootables en UEFI. Comme je n’en ai aucune (le PC fonctionne en Legacy), je n’ai pas d’entrée qui apparaisse, ce qui est somme toute assez normal.

Refindecran

III) Ajout des fichiers Supergrub2disk

Ici, je m’inspire de cet excellent travail de malbo, puisqu’il a réfléchi à la question bien avant moi.

On se rend sur le site de téléchargement du concepteur du logiciel (trouvé bêtement via une recherche sur Duckduckgo).

Une seule version étant proposée, à savoir un fichier ,super_grub2_disk_hybrid_2.02s9.iso on la télécharge. On vérifie son contenu en « ouvrant » l’iso avec le gestionnaire d’archives.

supergrub1

On copie le contenu sur la clé USB , le dossier [boot] excepté (on peut peut-être se limiter à Boot, mais là encore, je n’ai pas vérifié). On aboutit à ceci :

supergrub2

Il nous manque le dossier EFI qui va permettre de faire démarrer cette clé.

REM. J’ai tenté (avec succès) d’extraire le dossier EFI du fichier efi.img de Supergrubdisk pour l’ajouter à la racine, mais dans ce cas, le démarrage conduit à des erreurs. Donc, inutile de suivre cette voie.

Je pense que n’importe quel OS****  possédant ce fameux dossier pourrait convenir, mais nous allons utiliser l’iso de Linux Mint 18.

**** Eh bien non. Il faut utiliser un dossier EFI issu d’un Linux, car sinon, ça ne lance pas ce que l’on souhaite.

On ouvre l’image ISO de Linux Mint 18, et on constate que le dossier EFI est bien là :

supergrub3

On copie le dossier à la racine de la clé, ce qui donne le résultat suivant :

supergrub4

On a bien tous les fichiers nécessaires pour démarrer. Il ne reste plus qu’à lancer la clé USB en mode UEFI. Le programme se lance parfaitement, mais là encore, mon PC n’a pas grand-chose à faire booter dans ce mode.

supergrubecranOn constate néanmoins que Supergrub2 se lance parfaitement, tout comme Refind s’est lancé précédemment. On pourrait lancer un noyau Linux, et peut-être même, un Windows récalcitrant.

 

Réparer Windows après modification du path bootmgr pour dual boot Linux

Sur de nombreux tutoriels, on propose de contourner un blocage de l’installation de dual-boot en UEFI en modifiant le lancement de Windows, de la manière suivante :

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi

ou encore, si le secure-boot est activé :

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

Cette commande, souvent proposée sur les PC HP ou Toshiba, dont le bios-uefi est bloqué sur le lancement de Windows, permet en effet de faire croire au PC qu’il démarre sur Windows, alors qu’il va lancer en réalité le lanceur de Linux.

Mais qu’en est-il si l’on supprime les partitions Ubuntu, sans prendre de précaution ?

I. Situation initiale : suppression des partitions Linux

Une image étant préférable à un long discours, voilà une capture d’écran d’un dual-boot dont les partitions ont été modifiées :

Modif-Ws

On constate que les partitions Linux viennent d’être supprimées, mais que la modification de {bootmgr} est toujours opérationnelle. On va laisser les choses en l’état afin de voir quelles sont les conséquences. Il suffit de redémarrer le PC. Le résultat est le suivant :
gruboff

En toute logique, Grub ne trouvant plus les fichiers Linux, il renvoie un message d’erreur. Notre PC ne boote plus. Vérifions le bios-uefi :

ordre-bios

Windows boot manager est bien proposé, mais il ne fonctionne visiblement plus. Et aucune entrée Ubuntu n’apparaît pour modifier les choses.

II. Les réparations possibles

 1. La commande bcdboot

C’est la méthode « classique ». On va vérifier ce qu’elle est capable de faire dans une telle situation. On doit, dans ce premier cas, faire démarrer le PC sur le DVD d’installation (ou la console de réparation) et choisir l’option « réparer l’ordinateur ». On sélectionne les « options avancées, puis l’invite de commandes ». On tape la commande suivante :

bcdboot n:\windows /l fr-fr

La lettre N est à adapter. On voit sur l’image ci-dessous que mon démarrage pointe toujours vers Grub, et que mon Windows est sur le volume D. J’ai donc remplacé N par D.

bcdboot

On va vérifier le résultat via la commande bcdedit /v : le démarrage a bien été modifié, de même que le path de {bootmgr} :

bcdboot-result

Le PC doit redémarrer normalement, et en effet :

redemarrage

 2. La commande bcdedit

Comme dans le précédent exemple, il va falloir utilise le DVD d’installation ou la console de réparation. Mais cette fois, on va modifier directement le path de {bootmgr} :

bcdedit2

On voit le résultat. La ligne path est modifiée, et on pointe bien vers le fichier bootmgfw.efi. Le résultat est identique : redémarrage sans problème.

redemarrage

 3. Le bios-uefi.

On peut également, si le bios le permet, modifier le chemin vers lequel l’entrée « Windows Boot Manager » est dirigée. Sous VMware, c’est assez facile :

biso

L’image se suffit à elle-même. On va chercher le fichier dans son dossier pour permettre à l’entrée sélectionnée de booter correctement. Les bios étant spécifiques à chaque marque, ce dernier moyen n’est donné que pour information.