web-dev-qa-db-ja.com

16.04 Lenovo Yoga 2 Proでのデュアルブートインストール-Windowsに再起動した後に/EFI/ubuntu/grubx64.efiが見つからない

他のスレッド、特にWindows 8.1を実行しているLenovo Yoga 2 Proでのデュアルブートインストールについて読んでいますが、まったく同じ問題を見つけることができなかったようです。私は確かにこれに初めて参加した（Ubuntuをインストールしようとするのは初めて）ので、これについて詳しく知る機会があれば幸いです！

パーティション用に約60GB、スワップ用にさらに8GBを確保しました。また、/dev/sda2パーティションにgrubをインストールしました。これは、WindowsブートマネージャーもあるESPです。

BIOS起動メニューで、ubuntu/grubが最初に起動するように指定しました。セキュアブートとLenovo Fast Bootは両方とも無効です。

これまでのところ、すべて順調です。起動すると、grubが表示され、UbuntuとWindowsブートマネージャーを選択できます。 Ubuntuを選択すると、Ubuntuにアクセスしたり、ログインしたりすることができます。代わりにWindowsを起動することを選択すると、問題が始まります。それを行い、シャットダウン/再起動してUbuntuを起動しようとすると、次のメッセージが表示されます。

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

Windows側で、存在しないと主張されているファイルが実際に指定されたフォルダーにあることを確認しました。それらは、bcdedit/enumファームウェアを使用して検出されました。

私もコマンドを使用してみました

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

管理者コマンドプロンプトで運がありません。

この後、USBからライブブートし、ブート修復を行い、GRUBを修正しました。Windows側に再びブートするまで、同じ問題が発生しました。

どんな助けでも大歓迎です、そして、私は役に立つかもしれない他のどんな情報でも提供しようとします。ありがとう！

16.04dual-bootgrub2uefilenovo
3
tigerwins

efiは、デフォルトのブートローダーが/efi/boot/bootx64.efiであることを期待しています。 windowsは、確実に起動するようにします。

まずは、Windowsの8.1から実際にはシャットダウンせず、ディスクをサスペンドして（休止状態のように）起動を高速化します。次に、ブート順で最初にエントリ0000（ウィンドウ）を作成するようにEFIを変更します。

回避策：grubx64.efiの名前をbootx64.efiに変更し、ファイルefi/boot/bootx64.efiを置き換えます。これにより、grubがデフォルトのブートローダーになります。

2番目：ubuntuの場合、efibootmgrを使用してすべてのefiエントリを削除します。コンピューターを再起動します。起動する最初のシステムがubuntuであることを確認して、エントリ0000に配置します。その後、Windowsを起動します。

4
ravery

Failed to open、Failed to load image、およびstart_image() returned Not FoundメッセージはShimからのものです。 （ ソースコード; を確認できます。これらはshim.cファイルにあります。）通常、EFIベースのコンピューターでUbuntuを起動すると、システムはUbuntuの方法であるShim（shimx64.efi）を起動します。セキュアブートを扱います。その後、ShimプログラムはGRUB（grubx64.efi）を起動します。これらのエラーメッセージは、Shimが起動したが、GRUBが存在しないか、読み取れないことを示しています。あなたが書いた：

Windows側で、存在しないと主張されているファイルが実際に指定されたフォルダーにあることを確認しました。

これは、grubx64.efiが存在するが、Shimが読み取れないことを示します。 Windowsが見るものとEFIが見るものとの間のこの不一致の最もありそうな説明は、Windows Fast StartupやHibernate機能が有効になっていることです。これらの機能は、次回の起動を高速化するために、Windowsのシャットダウン操作をディスクへのサスペンド操作に変換します。問題は、この機能により、ESP上のファイルシステムを含むファイルシステムが矛盾した状態のままになる可能性があることです。これにより、ESPからファイルを読み取るEFIの機能が破壊される可能性があります。一部のファイルはランダムに消えるように見える場合があります。一般的な規則として、EFI FATファイルシステムドライバーはWindowsまたはLinuxのFATドライバーほど堅牢ではないようです。そのため、Windowsではファイルは問題ないように見えますが、EFIからは読み取れません。

解決策は、それぞれ here および here、 で説明されているように、Windows Fast StartupおよびHibernate機能を無効にすることです。

また、ファイルシステムの損傷が他の何らかの方法で発生した可能性もありますが、Windowsドライバーはたまたま問題を回避できますが、EFIドライバーはできません。 ESPでディスクチェックツール（UbuntuのdosfsckやWindowsのCHKDSKなど）を実行すると、問題が解決する場合があります。極端な場合、バックアップ、新しいファイルシステムの作成、および復元が必要になる場合があります。

Raveryの解決策は単なるバンドエイドであり、リスクのあるものであることに注意してください。 （ファームウェアのすべてのブートエントリを削除した後、少なくとも1台のコンピューターがひどくフレークし始めたのを見ました。）EFI/BOOT/bootx64.efiのフォールバックファイル名へのGRUBのコピーは、場合によっては動作する可能性があります。 、ただし適切なEFIブート変数がない場合、一部のEFIはフォールバックブートローダーよりもWindowsブートローダーを優先します。さらに悪いことに、raveryのソリューションは問題の根本的な原因に対処していないため、再発するか、他のファイルシステムの損傷が発生し、他の問題が発生する可能性があります。 （幸いなことに、ESP上のファイルの数は比較的少ないので、システムが完全に破壊されることはないでしょう。WindowsおよびUbuntuの回復ツールは、破損したESPファイルを復元できます。）

フォールバックファイル名の使用以外のEFIシステムの起動方法の詳細については、以下を参照してください。

3
Rod Smith