Je me rends compte que vous avez résolu le problème, mais je tiens à souligner ce qui s'est mal passé et comment il devrait être résolu (à la fois par les utilisateurs finaux et par les développeurs d'Ubuntu).
Premièrement, les développeurs d'Ubuntu ont décidé - le plus imprudemment - de créer une configuration GRUB qui repose sur des fichiers dans la /partition racine Ubuntu ( ), ainsi que sur la partition système EFI (ESP). Cela rend GRUB vulnérable à la suppression ou à l'endommagement de la partition Linux, et rend donc difficile le démarrage de l'ordinateur après la suppression d'Ubuntu ou si l'installation d'Ubuntu est endommagée d'une manière ou d'une autre. Cette vulnérabilité est inutile; il est possible de configurer GRUB pour rechercher tous ses fichiers de support et de configuration sur l'ESP. Si GRUB était configuré de cette manière (comme le fait Fedora), la suppression d'Ubuntu n'affecterait pas la capacité de GRUB à rediriger vers Windows. Le système démarrerait toujours via GRUB, mais il redémarrerait au moins. Donc, honte à Ubuntu d'avoir mal configuré GRUB.
Deuxièmement, sur la base des noms de fichiers que vous avez mentionnés, vous semblez avoir exécuté l'outil de réparation de démarrage d'Ubuntu à un moment donné. Cet outil renomme automatiquement le chargeur de démarrage Windows EFI/Microsoft/Boot/bootmgfw.efiet place une copie de GRUB à sa place. Il fait la même chose avec le chargeur de démarrage de secours EFI EFI/BOOT/bootx64.efiet dépose une autre copie de GRUB dans as EFI/Microsoft/Boot/bootx64.efi, pour des raisons que je ne prétends pas comprendre. Il s'agit d'une solution de contournement pour un bogue dans une poignée d'EFI. Le problème est que Boot Repair fait cela par défaut. Sur la plupart des ordinateurs, ce n'est pasnécessaire. Lorsqu'il est par la suite souhaitable d'apporter des modifications à la configuration de démarrage, ce changement de nom et réplication de GRUB devient une complication, car les utilisateurs doivent deviner ce qui se passe. Alors, honte aux développeurs de Boot Repair d'avoir été discrets sur leurs réparations. (Pour leur défense, cependant, il serait très difficile pour Boot Repair de détecter de manière fiable les ordinateurs qui ont les bogues qui nécessitent le déplacement des fichiers de démarrage comme il le fait par défaut.)
Un autre point est important: dans un système EFI fonctionnant correctement, une liste de programmes de démarrage est conservée dans la NVRAM. L'EFI essaie chacun des programmes de cette liste en séquence; si l'un échoue ou est absent, le suivant est jugé. Lors de l'installation d'Ubuntu, il ajoute sa version de GRUB en haut de la liste. La plupart des EFI permettent également aux utilisateurs de spécifier le programme de démarrage à utiliser à partir d'un gestionnaire de démarrage intégré, mais ce gestionnaire de démarrage intégré est grossier sur la plupart des EFI.
Additionnez tous ces facteurs et la solution la plus simple au problème d'origine devient:
- Annulez les modifications de l'outil Boot Repair. Cela peut être fait à l'aide de l'outil Boot Repair lui-même; il dispose d'un menu Options avancées avec une case à cocher intitulée «Restaurer les sauvegardes EFI». Utilisez-le et les multiples copies de GRUB seront supprimées et le chargeur de démarrage de Windows sera restauré. Alternativement, cela peut être fait manuellement. Plus important encore, la sauvegarde de
bootmgfw.efi(probablement appelée bkpbootmgfw.efi, bien que certaines versions de Boot Repair aient utilisé d'autres noms) doit être copiée EFI/Microsoft/Boot/bootmgfw.efisur l'ESP.
- Supprimez GRUB dans son emplacement officiel / approprié -
EFI/ubuntu/grubx64.efipour Ubuntu. Si Secure Boot était actif, la suppression EFI/ubuntu/shimx64.efiserait nécessaire à la place. En fait, supprimer le EFI/ubunturépertoire entier , ou du moins le renommer, ferait l'affaire dans tous les cas.
C'est ça. Avec ces deux choses accomplies, l'EFI sautera l'option de démarrage Ubuntu car elle n'est plus valide et continuera à démarrer Windows. Certains EFI supprimeront également automatiquement l'option de démarrage Ubuntu des menus de leurs gestionnaires de démarrage, bien que cette pratique ne soit pas universelle.
Notez que dans votre cas, Matthew, je ne recommande pas de faire ces choses; vous avez une configuration qui fonctionne, et comme on dit, "si ce n'est pas cassé, ne la réparez pas." Vous pouvez avoir quelques fichiers perdus sur votre ESP, mais ils ne font aucun mal, il est donc préférable de le laisser tranquille. J'ai présenté ma réponse dans l'espoir que quelqu'un d'autre la trouvera utile.
EDIT: Ce qui précède était correct lorsque je l'ai écrit pour la première fois, et les principes restent les mêmes; cependant, Boot Repair ne renomme plus automatiquement le chargeur de démarrage Windows et le remplace par une autre copie de GRUB. (La réparation de démarrage peut le faire en option, mais l'option est enterrée dans un menu d'options avancées, elle n'est donc plus effectuée par défaut.) Ce fait rend la récupération de ce problème plus facile aujourd'hui qu'elle ne l'était en 2013. Dans la plupart des cas, vous n'avez besoin que supprimez le EFI/ubunturépertoire de l'ESP pour faire démarrer le système directement sur Windows. Si GRUB apparaît toujours après cela, vous avez peut-être utilisé l'option Boot Repair pour sauvegarder et renommer les fichiers de démarrage, auquel cas son utilisation pour annuler ces actions est en règle, comme indiqué précédemment.
Une autre option consiste à utiliser le gestionnaire de démarrage intégré de l'ordinateur (généralement accessible en appuyant sur une touche de fonction, Esc ou Entrée peu de temps après avoir allumé l'ordinateur) pour contourner GRUB et démarrer sur Windows. Vous pouvez ensuite utiliser EasyUEFI pour ajuster l'ordre de démarrage et / ou supprimer l' ubuntuentrée de la liste de démarrage. Cette action ne supprimera pas GRUB de l'ESP, mais elle contournera GRUB.