USBなしでは起動できず、grub-installとboot-repairの両方が失敗しました

Question

更新＃4：予測どおり、起動順序のリセットは機能しませんでした：Sudo efibootmgr -o 4,0,1,2は何もしませんでした。

アップデート＃3：下を参照

アップデート＃2：HPの問題が原因の可能性があります。ロッドの答えをご覧ください。この問題は未解決のままです。

更新：ブート修復を行いましたが、機能しませんでした。詳細については、下部のセクションを参照してください。

Ubuntu起動USBを備えた新しい2017 HP EliteBookにUbuntu 16.04.2 LTSをインストールしました。 Ubuntuを削除するために、Windowsを消去しました。ただし、スタートアップ（下記のUEFIの詳細を参照）は、USBを挿入しない限りオペレーティングシステムを見つけることができませんでした。

この答えに基づいて私は試しました：

Sudo grub-install /dev/sda

しかし、私はエラーを得ました：

I386-pcプラットフォーム用のインストール。
grub-install：エラー：「aufs」の標準パスの取得に失敗しました。

それからこの回答からの提案を試してみましたが、同じエラーが出ました。

Sudo grub-install /dev/sda2

実際にハードドライブにインストールしたかったため、次のように識別されます。

Sudo fdisk -l Device ... Size Type /dev/sda1 512M EFI System /dev/sda2 208.1G Linux filesystem /dev/sda3 15G Linux swap

しかし、Sudo fdisk -lでブートをgrepできませんでした。

このコマンドに基づいて、問題は私のルート/がaufsにある可能性があると思います。

> df Filesystem .. ... Mounted on udev /dev aufs /

詳細：

ラップトップには200 GB SSDがあります
Ubuntuをインストールすると、UEFIがBIOSオペレーティングシステムを損傷する可能性があるという警告が表示されました。レガシーを使用する場合、Ubuntu USBドライブも認識しないため、ブートをレガシーではなくハイブリッドブートとして残しました。次に、Ubuntuのインストール中にUEFIを強制的にインストールします。（まだWindows 10を使用していた場合、BIOSを使用していた可能性があり、明確な答えを得ることができませんでした。）

更新：私は boot-repair を「Ubuntuにboot-repairをインストール」オプションで試し、これを取得しました paste2 、シャットダウンし、USBを取り出し、オンにして、：

BootDevice Not Found Please install an operating system on your hard disk.

私は今どうすればいい？

アップデート＃3：

USBを接続したUbuntuを試すのSudo efibootmgrとdfの結果を次に示します。

質問：

明らかに、ブート順序が最初にUSBに、Ubuntuが最後にならないように変更する必要があります。上に移動するにはどうすればよいですか？
.efiファイルに問題がある可能性がある場合。名前を正確に変更する必要があるものと、その方法について混乱しています。現在、ブートUSBは/ cdromにマウントされています。ただし、/ cdrom/EFIにはBOOTのみがあります。/cdrom/EFI/BOOTには次のファイルがあります。
```
BOOTx64.efi grubx64.efi 
```
2a。 SUBマウントを/ cdromから/ mntに何らかの方法で変更する必要がありますか？

2b。どのファイルをどの名前に変更する必要がありますか？なぜなら….

bfan1 says "/EFI/ubuntu/shimx64.efiの名前を/EFI/ubuntu/bootmgfw.efiに変更

「推奨されるフォールバックとして、ディスクブートローダー/EFI/Boot/bootx64.efiを/EFI/ubuntu/shimx64.efiのコピーとして設定します。shimx64.efiには同じディレクトリにgrubx64.efiが必要なので、コピーします/EFI/ubuntu/grubx64.efiから/EFI/Boot/grubx64.efi

「インストールメディアで使用したものとまったく同じセットアップを見つけました。/cdrom/EFI/BOOT/BOOTx64.efiは、実際にはshimx64.efiのコピーです。これが、UEFIモードでデフォルトのブートローダーを使用してインストールメディアを起動する方法です。

そして

Rod Smithは comment で、「プライマリブートローダーまたはブートマネージャーファイルの名前をEFI/BOOT/bootx64.efiに変更するハック的な回避策を検討する必要があります」と述べています。

よくわかりません

Rod Smith · Answer

Sudo grub-install /dev/sda

しかし、私はエラーを得ました：

Installing for i386-pc platform. grub-install: error: failed to get canonical path of `aufs'.

知っているかどうかにかかわらず、/dev/sdaデバイスをgrub-installに渡すことは、GRUBのBIOSモードバージョンのインストールを意味します。（もちろん、このオプションを誤って渡した可能性があります。）同様に、GRUBがi386-pc platformに対してインストールしようとしている応答は、BIOSモードGRUBのインストールも意味します。 failed to get canonical path ofaufs'`メッセージの意味がわからない。ただし、GRUBのBIOSモードバージョンは重要です。

Sudo fdisk -l Device ... Size Type /dev/sda1 512M EFI System /dev/sda2 208.1G Linux filesystem /dev/sda3 15G Linux swap

EFI System Partition（ESP）の存在は、ディスクがBIOSモードではなくEFIモードで起動するように設定されていることを意味します。（補足として、fdiskコマンドからの出力行を明確にカットしました。ヘルプを求めているときは、これを行うべきではありません。これらの行は、probablyこの特定のケースでは冗長。

今日の新しいコンピューターの大部分は、デフォルトでEFIモードで起動するように構成されています。ファームウェアでBIOS/CSM /レガシーモードのサポートを有効にできます。UbuntuおよびLinuxのインストール手順の中には、有効にすることを推奨するものがあります。ただし、ほとんどの場合、これは悪いアドバイスです。件名のマイページを参照して、理由を確認してください。これらの変更を自分で行ったかどうかは不明です。 UbuntuインストールにBIOSモードバージョンのGRUBが存在することは、BIOSモードでインストールしたことを示唆しています。ただし、ディスクのパーティション分割は、EFIモードでインストールしたことを示唆しています。

これは新規インストールであるため、私の推奨事項は、EFIモードでonlyを起動するようにファームウェアを構成し、EFIモードブートローダーをインストールすることです。これを行うには多くの方法があります。最も簡単な3つは次のとおりです。

EDIT：

ブート修復の出力から、問題の原因への手がかりがいくつかあります。

File system: vfat Boot sector type: FAT32 Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files: /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi /EFI/ubuntu/fwupx64.efi /EFI/ubuntu/grubx64.efi /EFI/ubuntu/shimx64.efi /EFI/Microsoft/Boot/bootmgfw.efi /EFI/Microsoft/Boot/bootx64.efi

特に、Microsoftブートファイル（/EFI/Microsoft/Boot/bootmgfw.efiおよび/EFI/Microsoft/Boot/bootx64.efi）の存在に注意してください。これらのファイルは、ESPを削除していないことを示唆しているため、WindowsブートローダーファイルはUbuntuインストールと一緒に潜んでいるようです。また、efibootmgrの出力を確認します。

=================== efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds No BootOrder is set; firmware will attempt recovery Boot0000* USB Hard Drive 1 - Generic Mass Storage BBS(HD,,0x900)....................................................................... Boot0001* Notebook Hard Drive BBS(HD,,0x0)....................................................................... Boot0002* Notebook Ethernet BBS(128,,0x0)....................................................................... Boot0003* Windows Boot Manager HD(1,GPT,2c19863f-1ed0-476e-a8e9-6d316ca2c4bb,0x800,0x32000)/File(EFIMicrosoftBootbootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................ Boot0004* ubuntu HD(1,GPT,17667422-8dfe-45ba-9baa-5458a67b71db,0x800,0x100000)/File(EFIubuntushimx64.efi)

Windowsブートエントリもそこにまだ存在していますが、これは驚くことではありません。ただし、本当に混乱しているのは、No BootOrder is set; firmware will attempt recoveryというレポートです。動作しているEFIは、BootOrderという変数に依存して、ブートローダーが実行される順序を識別します。この変数はコンピューターにはありません。私が所有しているかなり古いHP 6470bラップトップでも同じ問題が発生しており、何を試しても、この変数を作成できませんでした。いずれにしても、可能性のある結果は、コンピューターがフォールバックブートローダー（EFI/BOOT/bootx64.efi）またはMicrosoftブートローダー（EFI/Microsoft/Boot/bootmgfw.efi）を起動しようとしていることです。起動されたブートローダーが元のMicrosoftブートローダーである場合、Windowsがインストールされていないため、この時点でフレークアウトします。それらのファイルに何か他のものをコピーした場合（故意かそうでないかにかかわらず）、サポートファイルも存在しない場合はフレークする可能性があります。

お使いのコンピューターは新品だと言うので、私の最初の推奨事項は、コンピューターをストアに返品して払い戻しを行い、別のものを購入することです。問題はサンプルの欠陥（不良NVRAMチップなど）であるか、HPのファームウェアのバグである可能性があります。前者の場合、同じコンピューターの新しいバージョンが機能する可能性があります。しかし、バグのあるファームウェアの場合、新しいコンピューターは何もしません。（OTOH、バグのあるファームウェアの場合、ファームウェアの更新で問題が修正される可能性はわずかです。ファームウェアオプションをデフォルトにリセットすることも役立つ場合があります。）返金のためにコンピューターをストアに戻す場合は、必ずHPに伝えてくださいあなたはそれをしました、そしてその理由。メーカーは、そうしているという事実に気づいていない限り、欠陥のある製品を販売し続け、そうするために（返品という形で）苦痛を感じます。

壊れていないコンピューターの入手を拒否する場合は、対処する必要があります。最良の方法は、これらのWindowsブートローダーファイルをESPから削除し、GRUBをEFI/BOOT/bootx64.efiのフォールバックファイル名にコピーすることです。（その場所には既にファイルがありますが、GRUBの別のコピー、Windowsブートローダーの別のコピー、または他の何かであるかどうかは明らかではありません。）grub.cfgおよびおそらく他のファイルをEFI/ubuntuからEFI/BOOTも。ブート修復を使用する場合、[詳細]ページにこれを半自動的に実行するオプションがあります。

編集2：

次のように、-oオプションを使用して、efibootmgrにブート順序を変更できます。

Sudo efibootmgr -o 4,0,1,2

この例では、既存のブートエントリを表示したままにしますが、ubuntuエントリを先頭に追加します。理論的には、これによりGRUBがデフォルトのブートプログラムになり、すべてが動作し始めます。 man efibootmgrと入力すると、efibootmgrの詳細を確認できます。（他のコマンドでも同じトリックが機能します。たとえば、man lsはlsコマンドについて通知します。）

そうは言っても、最初に存在しないBootOrder変数があったという事実は、これが機能するかどうか懐疑的です。 EFIが失敗する原因となるような不安定なものがあると思います。（元のUbuntuのインストールとブート修復の両方shouldは、ubuntu変数の先頭にBootOrderエントリを追加しました（EFIモードで実行されたと仮定します-およびブート修復示した出力では、ディスクにBIOSモードのブートローダーがないことがわかりました。これは、EFIモードで実行されたことを意味します。

システムにはtwoEFIシステムパーティション、またはその目的を満たすパーティションがあり、混乱していると思います。

ハードディスク上-ブート修復出力によると、ハードディスク上のESPは/dev/sda1です。このパーティションは、ハードディスクでUbuntuを起動するときに/boot/efiにマウントする必要があります。ただし、「インストールする前に試す」モードでUbuntuインストールメディアを使用する場合、自動的にマウントされないか、IIRCの/mediaのサブディレクトリにマウントされます。
インストールメディア上-technicallyではありませんが、インストールメディア上の/dev/sdb1は同じものを提供します役割。 EFI/BOOTディレクトリにさまざまなブートファイルが含まれています。インストールメディアを使用せずにインストールされたOSからシステムを起動したいので、これらのファイルの調整は少なくともせいぜい無意味です。

インストールディスクで起動する場合、ハードディスクのESP上のファイルを変更するには、ESPをマウントしてからそれらのファイルを変更する必要があります。あなたはこのようなことをするでしょう：

Sudo mkdir -p /mnt/foo Sudo mount /dev/sda1 /mnt/foo cd /mnt/foo/EFI Sudo mv Boot Boot-old Sudo cp -r ubuntu BOOT Sudo mv BOOT/shimx64.efi BOOT/bootx64.efi

タイプミス（私またはあなた）がこれらのコマンドを期待通りに動作させない可能性があり、そのような間違いは事態をさらに悪化させる可能性があることに注意してください。動作する場合、この一連のコマンドはShim（セキュアブート認証を処理する）をEFI/BOOT/bootx64.efiのフォールバックファイル名にコピーします。その後、ShimはGRUB（grubx64.efi）を起動し、ブートプロセスを続行します。前に説明したefibootmgr -oコマンドが機能しない場合、このシーケンスでシステムが起動するはずです。

これを超えて、あなたはかなり基本的な質問をたくさんしているので、この質問とその答えをもつれたウェブに変えています。私はあなたが外部の読書をすることをお勧めします：

これらの基本事項のいくつかを理解すると、ここから答えをさらに得ることができますが、不完全な初期情報と誤った推測のために、私たちがいくつかの盲目の路地を進んでいることに注意してください。上記の少なくともいくつかを読んでも問題が解決しない場合は、新鮮な質問をするか、 buntuフォーラムに議論することをお勧めします。（このサイトは、比較的簡単な質問に回答することを目的としており、詳細な議論は行いません。）

ubfan1 · Answer

Boot-repairは、ペーストリンクのefibootmgrの最後の実行で、項目0004としてubuntu shimx64ブートエントリを追加したようです。 0004は、以前のefibootmgrの実行（貼り付け）で欠落していました。
VVVVを編集
efibootmgrの最新の手動実行では、項目がリストされていても、ブートオーダーに0004がありません。自分で追加してください：

Sudo efibootmgr --bootorder 0004,0000,0001,0003,0002

先行ゼロはオプションですが、上記のエントリは表示されているとおりに使用されます。
編集^^^^

ただし、これはHPであり、UEFIにベンダー固有の調整がいくつかあり、標準セットアップが壊れています。基本的に、ブートローダーに必要な特定の承認済みの名前を追加します（Windowsブートローダー）。さらに、ブートローダーのファイル名はbootmgfw.efiでなければなりません。 efibootmgrを使用して、ブートローダーエントリの名前を変更できます。

Sudo efibootmgr -b 0004 -l /EFI/ubuntu/bootmgfw.efi -L "Windows Boot Loader"

/EFI/ubuntu/shimx64.efiの名前を/EFI/ubuntu/bootmgfw.efiに変更するだけです
VVVVを編集
名前の変更は、ハードディスク上のファイルです。 dfは、ハードディスクのEFIであるsda1がどこにもマウントされていないことを示しているため、マウントするまで、マウントした場所に表示される/ EFIディレクトリを見ることもできません。/cdromディレクトリの下には何も触れないでください。
編集^^^^

これでうまくいくはずです（HP UEFIの問題についてはこのサイトを検索してください。しかし、それは解決策を要約していると思います）。

VVVの編集ハードディスクのEFIパーティションを/ mntにマウントします

Sudo mount -tvfat /dev/sda1 /mnt

これで/ mntの下に、ハードディスクのsda1パーティションのEFIディレクトリが表示されます。すべての変更は、これらのファイル/ mnt/EFI/ubuntu/...および/ mnt/EFI/Boot/...に対して行われます。
編集^^^

フォールバックとして（推奨）、ディスクブートローダー/mnt/EFI/Boot/bootx64.efiを/mnt/EFI/ubuntu/shimx64.efiのコピーとしてセットアップします。 shimx64.efiは同じディレクトリにgrubx64.efiを必要とするため、/ mnt/EFI/ubuntu/grubx64.efiを/mnt/EFI/Boot/grubx64.efiにコピーします

そのフォールバックブートローダーは、nvramブートエントリとは無関係に機能する場合があり、nvramブートリストを変更することが決定された場合、ブートを機能させ続けます。

しばらく前、デュアルブート、セキュアブートが有効なホストで、ubuntu/shimを最初のnvramエントリとして使用し、USBスティックにインストールメディアを作成した後、shimx64エントリをgrubx64.efiに変更しました（もちろん正常に動作しません）セキュアブートを有効にして起動します）。 UEFIには、USBインストールメディアの作成時にさらに深刻な問題があるため、最終的にデフォルトシステムをレガシーモードで実行するように変更しました。
インストールメディアで見つけたもの、/ cdrom/EFI/BOOT/BOOTx64.efiは、実際にはUSBのブートファイルです。動作するため、変更しないでください。 BOOTx64.efiはshimx64.efiの単なるコピーであることに注意してください。これは、UEFIモードでデフォルトのブートローダーを使用してインストールメディアを起動する方法です。この正確なセットアップ（大文字と小文字を区別しない）は、フォールバックとしてハードディスクに配置するものです。

「既にマウントされている」ためにSudoマウント/ dev/sda1/mntが失敗した場合は、dfを使用して場所を確認しますが、それを行わなかった場合は奇妙です。これは/ cdrom/EFIではなく、ディレクトリです（ただし、bootx64.efiおよびgrubx64.efiがハードディスクに置く別のソースです）。おそらく、ディスクは再列挙され、ハードディスクはsdbになり、sdaはUSBのままになりました。 dfの内容を確認し、その場合はマウントを/ dev/sdb1に変更します。