Archives mensuelles : juin 2017

Le cas « Bootmgr is missing » sous W7

Pour une fois, je ne propose ni solution ni démonstration, mais un bilan en relation avec cette panne, très fréquente sous W7, et qui est souvent traitée sur les forums de manière absurde :

bootmgr

Alors, on trouve de nombreux tutoriels qui prétendent régler ce problème de manière unilatérale, et la plupart proposent  de réécrire, par tel ou tel moyen, le fichier bootmgr.exe qui semble avoir disparu. En voici trois parmi d’autres :

On pourrait ajouter la commande bcdboot, une copie via xcopy des fichiers de démarrage, etc. Tous semblent suggérer que les fichiers bootmgr.exe ou bcd sont manquants et à reconstruire.

Eh bien, soyons clairs, aucune de ces solutions n’est fiable, celle de M$ y compris. Pourquoi ?

Le message survient dès lors que le Bios Legacy identifie la présence d’un disque dur doté d’un MBR NT6.1, et sur lequel une partition, quelle qu’elle soit, est active. Eh bien, c’est exactement la méthode que j’ai utilisée ici : en bootant sur une clé de réparation W7, et en lançant quelques commandes, on voit parfaitement ici qu’un disque vide a suffi à générer ce message :

vide

La  commande « diskpart » confirme qu’il a suffi d’activer la partition vide pour engendrer le message d’erreur :
activeCa signifie donc que le message peut être provoqué par de multiples causes. J’en énumère quelques-unes :

  • Partition de démarrage qui a été formatée. (le plus fréquent),
  • Drapeau boot (ou active) déplacé sur une mauvaise partition. C’est parfois le cas avec les restaurations d’usine.
  • Une clé usb active oubliée dans le pc. On oublie souvent de supprimer le drapeau boot sur les clés USB.
  • Fichier bootmgr.exe HS ou autre fichier de démarrage corrompu dans \boot . C’est finalement assez rare.
  • Partition système passée en raw. Peu probable, mais parfois le format raw garde des traces du formatage NTFS, ce qui trompe le bios du PC.

Il est donc impossible de proposer une solution unique à un problème multiple, et il faudra toujours commencer par faire un point sur la situation du disque, et passer par un état des lieux initial :

diskpart
list disk
list vol
sel disk 0
list part
(sel disk 1  * Si on a plusieurs disques)
list part

On fait le point sur les partitions et volumes en place, afin de voir ce qu’on y trouve. Si on trouve la partition Système ou Reserved, on fera un point sur le détail de son état :

sel part 1 (  * on adapte le nombre à sa situation) 
detail part 
exit

Et enfin, si une lettre de volume lui est associée, on vérifiera la présence des fichiers de boot par

dir /a n:\b*           on adapte N à son cas pour trouver bootmgr
dir /a :n:\boot\b*     c'est en principe dans "boot" qu'on trouve BCD

On pourra faire une recherche graphique de ces fichiers, à l’image de ma seconde capture d’écran, avec l’éditeur notepad qui est bien utile en invite de commandes.

Bref, on cherche la cause du problème en identifiant la présence des fichiers de démarrage. C’est seulement une fois ceci de fait qu’on pourra poster un sujet dans un forum d’aide. Quelques exemples de dépannages réalisés (entre autres…) :

On notera qu’avec W8 qui utilise NT6.2 et les versions suivantes NT10, le message n’est plus le même si le disque est vide, si le fichier bootmgr est corrompu, ou si la base BCD est abîmée. Par exemple la même situation que celle de mon exemple aboutit à ceci :

bootmgr2

 

Quatre méthodes pour ajouter une entrée NVram en UEFI

En principe, l’ajout d’un système d’exploitation (Windows) gère intégralement et automatiquement le dual-boot en UEFI, et notamment les entrées NVram qui vont permettre au système de lancer tel ou tel système d’exploitation.

Par exemple, si on ajoute une distribution Ubuntu sur un PC Windows, l’installateur copie de lui-même tous les fichiers efi nécessaires au lanceur Grub, et il crée une entrée Ubuntu dans la NVram, ce qui permet au système de démarrer.

Mais parfois, l’opération échoue, et Windows continue de démarrer par lui-même. Mieux, on peut avoir envie d’ajouter un lanceur indépendant comme dans cet exemple où j’ai ajouté le lanceur Refind manuellement (voir le lien précédent pour la mise en place des fichiers sur la partition efi). Il faut donc savoir paramétrer la NVram pour qu’une telle configuration fonctionne.  Nous allons voir quatre méthodes pour le faire.

I) L’ajout d’une entrée via l’UEFI

C’est en principe la méthode la plus naturelle, mais il faut que les options soient proposées. De plus, il y a tellement de version d’UEFI qu’il est difficile de proposer un tuto universel. Je présent la méthode depuis l’UEFI d’un PC Virtuel sous Vmware. On accède à l’UEFI en appuyant une touche préconisée par le constructeur (souvent F2). On obtient dans mon cas ceci :

bios1

On va utiliser l’option « Boot Maintenance Manager« , puis « Configure Boot Options«   et on choisit d’ajouter une entrée via « Add Boot Option« . Ce qui me conduit ici :

bios2On écarte les entrées inutiles (ici en CDROM en rouge, un disque Winre, une entrée MAC) et on sélectionne notre disque dur par entrée. Ceci conduit à une entrée <EFI>, puis à un choix entre <Microsoft>, <Boot>, <Ubuntu> et <REfind>. On choisit le dernier et on aboutit à une liste de fichiers :

bios3

Le fichier refind_x64.efi semble approprié. Une description est demandée (ici je saisis « mon-refind« ). On valide le tout : l’entrée est créée. Il faut encore la placer en tête. L’entrée « Configure Boot Options » conduit à une option « Change Boot Order » . Elle ouvre cette fenêtre :

bios4

Comme préconisé, on sélectionne l’entrée « Mon-Refind » par la touche entrée, et on la passe en première position. On enregistre. Et il ne reste plus qu’à redémarrer pour tester. Le démarrage se fait bien sur mon lanceur.

refnd-ok

La méthode fonctionne probablement très différemment sur l’UEFI d’un PC, cette méthode n’est proposée que pour information.

II) L’ajout d’entrée via un Linux installé.

En principe, il suffit de deux commandes pour ajouter une entrée Ubuntu sur un PC en UEFI :

essai@essai-virtual-machine ~ $ sudo grub-install
essai@essai-virtual-machine ~ $ sudo update-grub
Création du fichier de configuration GRUB…
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
No volume groups found
Windows Boot Manager trouvé sur /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
essai@essai-virtual-machine ~ $

On peut vérifier que l’entrée a été ajoutée en NVram. L’entrée Ubuntu liée à Grub a été ajoutée, et elle passée en première position dans la ligne bootOrder

essai@essai-virtual-machine ~ $ sudo efibootmgr 
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0004,0002,0003,0001,0008,0009,000A,000B,0000
Boot0000* EFI VMware Virtual SCSI Hard Drive (2.0)
Boot0001* Windows Boot Manager
Boot0002* REfind
Boot0003* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0004* ubuntu
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)
essai@essai-virtual-machine ~ $

Malheureusement, cette méthode ne permettrait pas d’ajouter l’entrée Refind, et c’est celle qui m’intéresse (et encore moins Windows). On va la supprimer pour mieux la recréer.  C’est très simple  (on obtient les détails de la commande avec l’extension -help. Notre entrée Refind a disparu.

essai@essai-virtual-machine ~ $ sudo efibootmgr -b 0002 -B
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0004,0003,0001,0008,0009,000A,000B,0000
Boot0000* EFI VMware Virtual SCSI Hard Drive (2.0)
Boot0001* Windows Boot Manager
Boot0003* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0004* ubuntu
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)

Première chose à faire, identifier le disque et les partitions.

essai@essai-virtual-machine ~ $ sudo parted -l
Modèle: VMware, VMware Virtual S (scsi)
Disque /dev/sda : 39,7GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt

Numéro  Début   Fin     Taille  Système de fichiers  Nom                           Fanions
 1      1049kB  473MB   472MB   ntfs                 Basic data partition          msftdata
 2      473MB   683MB   210MB   fat32                EFI system partition          démarrage
 3      683MB   817MB   134MB                        Microsoft reserved partition  msftres
 4      817MB   20,6GB  19,8GB  ntfs                 Basic data partition          msftdata
 5      20,9GB  39,2GB  18,3GB  ntfs                 Basic data partition          msftdata
 6      39,2GB  39,7GB  566MB   fat32                Basic data partition          msftdata

Le nom du disque est /dev/sda et la partition efi est la numéro 2. On n’a plus qu’à recréer l’entrée qui nous intéresse.

essai@essai-virtual-machine ~ $ sudo efibootmgr -c -d /dev/sda -p 2 -L "Refind-new" -l "\EFI\refind\refind_x64.efi"
Timeout: 2 seconds
BootOrder: 0002,0004,0003,0001,0008,0009,000A,000B,0000
Boot0000* EFI VMware Virtual SCSI Hard Drive (2.0)
Boot0001* Windows Boot Manager
Boot0003* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0004* ubuntu
Boot0008* EFI VMware Virtual SCSI Hard Drive (0.0)
Boot0009* EFI VMware Virtual SATA CDROM Drive (1.0)
Boot000A* EFI Network
Boot000B* EFI Internal Shell (Unsupported option)
Boot0002* Refind-new

Quelques explications: -c signifie « create », -d signifie « disque », -p signifie « partition », -L signifie « label » et -l indique le chemin du fichier refind_x64.efi précédemment trouvé. Il ne reste qu’à tester. Aucun problème, nous retrouvons notre démarrage sur Refind :

refnd-ok

 

III) Ajout d’une entrée via Windows.

Sous Windows, on peut utiliser deux moyens différents : l’un s’appuie sur une logiciel nommé EasyUEFI, et l’autre sur la commande bcdedit.

1) L’utilisation de EasyUEFI

J’ai déjà fait cette démonstration sur l’autre sujet, et par conséquent, je me contente d’en donner le lien : http://ikewdu.free.fr/creer-un-dual-boot-windows-winre-en-uefi/#easyuefi

2) L’utilisation de bcdedit

Un logiciel, c’est pratique, mais ça peut devenir payant. Donc, autant se préparer à utiliser les outils Windows. La commande bcdedit est là pour ça. Mon intention première était d’utiliser la commande bcdedit /create, mais en dépit de nombreux essais et de recherches infructueuses, j’ai renoncé à cette solution. Nous allons donc utiliser l’option /copy.

Première chose à faire, monter la partition efi avec une lettre Z (ou autre):

C:\windows\system32>mountvol z: /s
C:\windows\system32>

Ensuite, on fait un état des entrées présentes dans la NVRAM :

C:\windows\system32> bcdedit /enum firmware

Gestionnaire de démarrage du microprogramme
-------------------------------------------
identificateur          {fwbootmgr}
displayorder            {bootmgr}
                        {5463a4c4-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4ac-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4ae-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4af-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4b0-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4c6-4b6d-11e7-886a-ed04ad7ce4d1}
                        {5463a4c7-4b6d-11e7-886a-ed04ad7ce4d1}
timeout                 2

Gestionnaire de démarrage Windows
---------------------------------
identificateur          {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  fr-fr
inherit                 {globalsettings}
default                 {current}
resumeobject            {5463a4b6-4b6d-11e7-886a-ed04ad7ce4d1}
displayorder            {current}
                        {5463a4ba-4b6d-11e7-886a-ed04ad7ce4d1}
toolsdisplayorder       {memdiag}
timeout                 30

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4ac-4b6d-11e7-886a-ed04ad7ce4d1}
description             EFI VMware Virtual SCSI Hard Drive (0.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4ae-4b6d-11e7-886a-ed04ad7ce4d1}
description             EFI Network

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4af-4b6d-11e7-886a-ed04ad7ce4d1}
description             EFI Internal Shell (Unsupported option)

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4b0-4b6d-11e7-886a-ed04ad7ce4d1}
description             EFI VMware Virtual SCSI Hard Drive (2.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4c4-4b6d-11e7-886a-ed04ad7ce4d1}
device                  partition=\Device\HarddiskVolume2
path                    \efi\ubuntu\grubx64.efi
description             EFI VMware Virtual SCSI Hard Drive (0.0)

Application logicielle (101fffff)
--------------------------------
identificateur          {5463a4c6-4b6d-11e7-886a-ed04ad7ce4d1}
device                  partition=\Device\HarddiskVolume2
path                    \efi\refind\refind_x64.efi
description             EFI VMware Virtual SATA CDROM Drive (1.0)

C:\windows\system32>

Je constate que Bootmgr est l’entrée qui démarre en priorité, et que j’ai de nombreuses entrées vides comme le CD-Rom, le shell, etc. Je vais copier l’entrée bootmgr pour paramétrer ma nouvelle entrée. Je copie l’entrée en la renommant « Refind-bcd« .

C:\windows\system32>bcdedit /copy {bootmgr} /d "Refind-bcd"
L’entrée a été correctement copiée dans {5463a4c7-4b6d-11e7-886a-ed04ad7ce4d1}.

C:\windows\system32>

A ce stade, ma nouvelle entrée crée me donne un un nouvel identificateur que je copie. Je modifie mon device et mon path pour les rediriger vers z:\efi\refind\refind_x64.efi :

C:\windows\system32>bcdedit /set {5463a4c7-4b6d-11e7-886a-ed04ad7ce4d1} device partition=z:
L’opération a réussi.

C:\windows\system32>bcdedit /set {5463a4c7-4b6d-11e7-886a-ed04ad7ce4d1} path \efi\refind\refind_x64.efi
L’opération a réussi.

Et enfin, je passe ma nouvelle entrée en tête de liste dans fwbootmgr (le gestionnaire de firmware) :

C:\windows\system32>bcdedit /set {fwbootmgr} displayorder {5463a4c7-4b6d-11e7-886a-ed04ad7ce4d1} /addfirst
L’opération a réussi.

Il ne reste plus qu’à tester la nouvelle entrée dans le firmware. Et là encore :

refnd-ok

Ce n’est certes pas la méthode la plus simple, mais c’est la seule qui se fait depuis Windows, et sans logiciel tiers.  Et on aurait pu ajouter une entrée Windows, Linux ou autre.

Créer un dual-boot Windows / Winre en UEFI

La console de réparation de W10 peut-être lancée via le menu avancé ou par la commande

shutdown /o /r /t 00

Mais celle-ci est tributaire du bon fonctionnement de Windows, et parfois, on ne parvient pas à la faire démarrer autrement que par le lancement d’une clé USB, ce que certains réussissent à faire plus ou moins bien. On peut donc faire en sorte que Windows propose de la faire démarrer à la demande, via un double boot, ce qui permettra de l’avoir sous la main quand on en aura besoin.

I) Création d’une partition spécifique.

On commence par faire un point sur le partitionnement de notre disque, via le gestionnaire de disques de Windows :

Sans titre 1

On constate que notre PC contient une partition assez grande pour y retrancher 540 Mib environ, ce que nous allons faire via ce gestionnaire.

resize

La manipulation ne pose aucun problème. Il ne reste qu’à formater. Je choisis obligatoirement le formatage en fat32, pour que ma future console accepte de se lancer en UEFI.

formatfat32

Le formatage ne pose aucun problème, lui non-plus. On en profite pour associer le nom Winrepair à ce volume G, même si ce n’est pas indispensable. La première opération est terminée.

II) Création et copie des fichiers de la console.

Pour créer la console de réparation, nous allons utiliser le programme « recoverydrive.exe« , inclus dans W10, que nous pouvons lancer via la commande « exécuter » (accessible en cliquant droit sur le menu démarrer) :

recoverydrive-exe
Une fenêtre s’ouvre. Comme je ne souhaite pas copier les fichiers systèmes de Windows, mais uniquement la console de réparation, je décoche l’option proposée.

recoverydrive-exe2

Le programme ne permettant de cibler que des partitions NTFS ou  des clés USB, mon volume Winrepair ne m’est pas proposé. Je vais donc utiliser une clé USB temporairement, afin de pouvoir ensuite transférer mes fichiers vers la partition fat32. Ici, il s’agit du lecteur H.

recoverydrive-exe3

La clé se fabrique en une dizaine de minutes. Au terme de l’opération, il ne reste plus qu’à copier les fichiers de la clé usb vers le volume Winrepair.

Copy-cle-vers-partition

Aucun souci, là non plus. La copie se fait sans difficulté.

Copy-cle-vers-partition2

A ce stade, on possède une partition contenant notre console Winre, mais elle n’est pas en mesure de démarrer elle-même. Comment faire ?

III) Permettre à la console Winre de démarrer

1) Via le bios-UEFI

La plupart des Bios-UEFI permettent d’ajouter une entrée de démarrage, voire de lancer un fichier efi directement en agissant via la NVRam. Comme on a autant de solutions que de constructeurs et je fais mes essais sur PC virtuel , on va écarter partiellement cette option que chacun pourra expérimenter comme il le souhaite. La chose à retenir, c’est qu’on doit lancer le fichier \efi\boot\bootx64.efi de la partition Winrepair.

Voici un exemple d’ajout d’une entrée dans la NVRam avec le  logiciel EasyUEFI qu’on aura préalablement téléchargé. En temps normal, j’utilise l’invite de commande, mais ce logiciel fonctionnant bien, on va s’en servir.  On ajoute l’entrée en sélectionnant l’option « Linux et autre OS« , puis la bonne partition, et enfin, le bon fichier :

createNVRAM

L’entrée Windows-Repair étant ajoutée en dernière position, on va la faire monter dans la liste, pour la placer juste après notre entrée Windows Boot Manager correspondant à W10:

createNVRAM2

Cette solution obligera à passer par le bios-uefi ou par le menu de démarrage (voir touche spécifique à la marque du PC – ESC pour Asus, F9 pour HP, etc.) pour lancer la console de réparation, mais elle constitue une solution acceptable.

2) Via le démarrage de Windows.

C’est la méthode la plus propre. On va ajouter une entrée vers le bon fichier, ce qui permettra de l’exécuter. En temps normal, j’utilise l’invite de commandes, mais pour simplifier la démo, je vais utiliser le programme Easybcd, qui n’est plus à présenter.

On lance le programme qu’on a bien sûr téléchargé, puis on choisit d’ajouter une entrée en sélectionnant l’option Winpe.  Je pointe sur le disque G, qui est mon volume Winrepair, et sur le fichier \sources\boot.wim

Easybcd

Lorsque c’est fait, on obtient une nouvelle entrée qui se place en seconde position et qui devrait nous permettre de lancer à la fois Windows et la console :

Le résultat confirme notre attente :

dual-ws
L’essai de démarrage est concluant :
dual-ws2

L’unique inconvénient de cette méthode réside dans le fait que notre console dépend du démarrage de Windows. Si celui-ci vient à être défaillant, nous ne sommes pas certains de pouvoir lancer la console, et il faudra repasser par le premier point (le bios-uefi) pour pouvoir contourner le blocage.

3) Via un lanceur autonome : refind

Refind est initialement un lanceur prévu pour Linux et Mac, mais il présente deux intérêts:

  • Contrairement à Grub, il n’a pas besoin d’un Linux pour fonctionner.
  • On peut l’installer directement sur la partition efi depuis Windows.

La première chose à faire est de le télécharger sur le site du concepteur, Rod Smith : http://www.rodsbooks.com/refind/getting.html

Le premier lien (fichier bin) est le bon, ce qui permet d’obtenir un fichier Zip initialement installable sous Linux. On ne va pas utiliser l’ensemble du zip, mais un seul sous-dossier appelé « Refind« : on va le copier à la racine du volume C pour simplifier les manipulations à venir.

refind1

L’extraction ne pose aucun problème. On va devoir copier ce dossier dans son intégralité dans la partition efi qui sert au démarrage. Et là, on n’a pas d’autre choix que l’invite de commande.

D’abord, on attribue à cette partition efi une lettre Z :

C:\windows\system32>mountvol z: /s

On crée sur cette partition appelée maintenant Z un dossier \refind dans le dossier \efi

C:\windows\system32>md z:\efi\refind
C:\windows\system32>cd z:\efi\refind
C:\windows\system32>z:
z:\EFI\refind>

On copie l’ensemble du dossier extrait du zip dans le dossier \efi\refind :

Z:\EFI\refind>xcopy /s c:\refind\*.*
(ici, je coupe la liste des fichiers copiés)
99 fichier(s) copié(s)

On renomme le fichier refind.conf-sample en refind.conf. On ne touche pas au contenu car ça n’intéresse pas la démo, mais il faut savoir qu’il est paramétrable.

Z:\EFI\refind>ren refind.conf-sample refind.conf
Z:\EFI\refind>
Il ne reste plus qu’à ajouter une entrée vers ce nouveau Firmware dans la NVRam. Comme dans le point 1, on utilise le logiciel EasyUEFI pour faciliter les choses :

refind2

L’entrée étant créée, on va la passer en priorité dans la NVRam pour que le PC la lance directement.

refind3

On vérifie que le démarrage est opérationnel :

refind4

Refind va chercher de lui-même toutes les entrées qu’il juge exploitables pour le démarrage, dont ma partition Recovery.

Il est même capable de lancer le noyau Linux d’une distribution Mint, sans que Grub ne soit installé. Mon PC sait donc faire démarrer Windows, Mon Grub, ma partition de réparation, le noyau Linux de Mint, et ma clé USB. Et tout fonctionne très bien.