web-dev-qa-db-fra.com

16.04 Installation à double démarrage sur Lenovo Yoga 2 Pro - /EFI/ubuntu/grubx64.efi introuvable après le redémarrage de Windows

J'ai lu d'autres discussions, en particulier sur les installations à double amorçage sur Lenovo Yoga 2 Pro sous Windows 8.1, mais je ne semblais pas avoir trouvé exactement le même problème. Je suis certes un nouveau venu dans ce domaine (la première fois que j'essaye d'installer Ubuntu), alors j'apprécierais toute opportunité pour en apprendre davantage à ce sujet!

J'ai réservé environ 60 Go pour la partition et 8 autres pour le swap. J'ai également installé grub sur la partition /dev/sda2, qui est le ESP où se trouve également le gestionnaire de démarrage Windows.

J'ai spécifié que Ubuntu/Grub devrait démarrer en premier dans le menu de démarrage du BIOS. Secure Boot et Lenovo Fast Boot sont tous deux désactivés.

Tout va bien jusqu'à présent. Je peux démarrer, et grub apparaît, me permettant de choisir entre Ubuntu et Windows Boot Manager. Si je choisis Ubuntu, je peux entrer dans Ubuntu, me connecter, etc. parfaitement. Le problème commence lorsque je choisis de démarrer Windows plutôt. Une fois que je fais cela et que j'essaie d'arrêter/redémarrer et de démarrer Ubuntu, le message suivant apparaît:

Failed to open /EFI/ubuntu/grubx64.efi - Not Found  
Failed to load image /EFI/ubuntu/grubx64.efi: Not Found  
start_image() returned Not Found

J'ai vérifié du côté Windows que les fichiers prétendus ne pas exister sont en fait dans les dossiers spécifiés. Ils ont été détectés à l'aide du micrologiciel bcdedit/enum.

J'ai aussi essayé d'utiliser la commande

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

dans l'invite de commande de l'administrateur sans succès.

Après cela, j’ai démarré en direct à partir d’une clé USB et j’ai réparé le démarrage, ce qui a corrigé GRUB ... jusqu’à ce que j’ai redémarré sous Windows, à quel moment le même problème s’est produit.

Toute aide serait grandement appréciée et je tenterai de fournir toute autre information utile. Merci!

3
tigerwins

efi s'attend à ce que le chargeur de démarrage par défaut soit /efi/boot/bootx64.efi. Windows est particulièrement attentif au démarrage.

poing off, à partir de 8.1 sur Windows ne s’éteint pas vraiment, il se suspend au disque (comme une veille prolongée) pour qu’il s’amorce plus rapidement. en second lieu, il change EFI pour créer l’entrée 0000 (Windows) d’abord dans l’ordre de démarrage.

contournement: renommez grubx64.efi en bootx64.efi puis remplacez le fichier efi/boot/bootx64.efi.this fait de grub le chargeur de démarrage par défaut.

deuxième: lorsque vous êtes dans Ubuntu, utilisez efibootmgr pour supprimer toutes les entrées efi. et redémarrez votre ordinateur. Assurez-vous que le premier système que vous démarrez est ubuntu, de sorte qu'il soit placé dans l'entrée 0000. Ensuite, démarrez Windows.

4
ravery

Les messages Failed to open, Failed to load image et start_image() returned Not Found proviennent de Shim. (Vous pouvez vérifier le code source; ils se trouvent dans le fichier shim.c.) Normalement, lors du démarrage d'Ubuntu sur un ordinateur basé sur EFI, le système lance Shim (shimx64.efi), qui est la façon dont Ubuntu traite de Secure Boot. Le programme Shim lance ensuite GRUB (grubx64.efi). Ces messages d'erreur indiquent que Shim a été lancé mais que GRUB n'était pas présent - ou n'a pas pu être lu. Tu as écrit:

J'ai vérifié du côté Windows que les fichiers prétendus ne pas exister sont en fait dans les dossiers spécifiés.

Cela indique que grubx64.efi existe, mais n'est pas lisible par Shim. L'explication la plus plausible de cet écart entre ce que Windows voit et ce que voit EFI est que les fonctionnalités Windows Fast Startup et/ou Hibernate sont activées. Ces fonctionnalités transforment une opération d'arrêt Windows en une opération de suspension sur disque afin d'accélérer le prochain démarrage. Le problème est que cette fonctionnalité peut laisser des systèmes de fichiers, y compris le système de fichiers sur l'ESP, dans un état incohérent. Cela peut à son tour causer des ravages à la capacité de l'EFI de lire des fichiers à partir du ESP - certains fichiers peuvent sembler disparaître de manière aléatoire. En règle générale, les pilotes de système de fichiers EFI FAT ne semblent pas être aussi robustes que les pilotes FAT sous Windows ou Linux. Par conséquent, un fichier peut sembler OK sous Windows mais illisible pour EFI.

La solution consiste à désactiver les fonctionnalités Windows Fast Startup et Hibernate, comme décrit respectivement ici et ici, .

Il est également possible que les dommages au système de fichiers se soient produits d'une autre manière, mais que les pilotes Windows puissent contourner le problème, alors que les pilotes EFI ne le peuvent pas. L'exécution d'un outil de vérification de disque (comme dosfsck dans Ubuntu ou CHKDSK sous Windows) sur le ESP pourrait résoudre le problème. Dans des cas extrêmes, il peut être nécessaire de sauvegarder, de créer un nouveau système de fichiers et de le restaurer.

Notez que la solution de Ravery est juste un pansement - et un risque, à cela. (J'ai vu au moins un ordinateur commencer à s'effriter après avoir supprimé toutes les entrées de démarrage du microprogramme.) Copier GRUB dans le nom de fichier de remplacement de EFI/BOOT/bootx64.efi pourrait fonctionner dans certains cas (comme il en a apparemment dans le vôtre), mais en l’absence de variables d’amorçage EFI appropriées, certains EFI privilégieront le chargeur de démarrage Windows par rapport au chargeur de démarrage de secours. Pire encore, parce que la solution de Ravery ne résout pas la cause sous-jacente du problème, il peut se reproduire ou certains dommages au système de fichiers peuvent survenir, ce qui peut entraîner d'autres problèmes. (Heureusement, le nombre de fichiers sur le ESP étant relativement petit, vous ne risquez donc pas de vous retrouver avec un système complètement détruit; les outils de récupération Windows et Ubuntu peuvent restaurer des fichiers endommagés ESP. .)

Pour plus d'informations sur le démarrage des systèmes EFI, au-delà de l'utilisation du nom de fichier de secours, voir:

3
Rod Smith