web-dev-qa-db-ja.com

EFI \ boot \ bootx64.efi vs EFI \ ubuntu \ grubx64.efi vs /boot/grub/x86_64-efi/grub.efi vs C：\ Windows \ Boot \ EFI \ *

Windows 10 64ビットと一緒にUbuntu 19 64ビットをインストールしましたが、異なる場所に3つの異なるEFIファイルがあることがわかりました。

EFI\boot\bootx64.efi

EFI\ubuntu\grubx64.efi

/boot/grub/x86_64-efi/grub.efi

これら3つの違いは何ですか？

grubuefiboot-loader
5
Yousha Aleayoub

EFI\boot\bootx64.efi：フォールバックブートローダーパス

これは、64ビットX86システムのUEFIファームウェアが既存のNVRAMブート設定なしで検索する唯一のブートローダーパス名であるため、リムーバブルメディアで使用するものです。

Windowsは、ブートローダーのコピーをこのパスに自動的にインストールします。 GRUBをインストールするとき、grub-install（またはLinuxディストリビューションによってはgrub2-install）コマンドは、対応するブートローダーのコピーがまだ存在しない場合、ここにコピーすることもあります。必要に応じて、grub-install --removableを使用してフォールバックブートパスにインストールするように指示するか、grub-install --force-extra-removableを使用してフォールバックパス内の既存のブートローダーを上書きし、GRUBで置き換えることができます。

UEFI用のセキュアブート互換USBスティックを作成する場合は、shimのコピーをEFI\boot\bootx64.efiとして配置し、GRUBのコピーをEFI\boot\grubx64.efiとして配置する必要があります。これは、shimブートローダーがgrubx64.efiを探すためですshimブートローダーと同じディレクトリにあります。

永続的にインストールされたOSのブートローダーパス

オペレーティングシステムがUEFIシステムに永続的にインストールされている場合、クラシックBIOSには存在しなかった新しいステップが1つあります。ブートローダーをインストールすると、ファームウェア設定を保持するNVRAMメモリに4つのものが書き込まれます。

  • ブートローダーを保持するEFIシステムパーティション（ESP）上のブートローダーパス名
  • GUIDパーティションのESP
  • この特定のブートローダーインスタンスのわかりやすい（人にわかりやすい）名前
  • オプションで、ブートローダーのデータ

Windowsの場合、Windowsブートプロセスの標準UEFIパス名は\EFI\Microsoft\Boot\bootmgfw.efiで、わかりやすい名前は「Windowsブートマネージャー」です。オプションのデータには、WindowsブートローダーのBCD構成ファイル内の何かへのGUID参照が含まれているようです。

Ubuntuの場合、パス名は、セキュアブートサポートが必要ない場合は\EFI\Ubuntu\grubx64.efi、セキュアブートシムが使用されている場合は\EFI\Ubuntu\shimx64.efiにする必要があります。説明的な名前は単に「ubuntu」であり、オプションのデータは使用されません。

Ubuntuでは、これらのUEFI NVRAMブート設定はSudo efibootmgr -vコマンドを使用して表示できます。 Windowsでは、コマンドプロンプト管理者としてを起動してから、bcdedit /enum firmwareコマンドを使用して設定を表示できます。

UEFI仕様には、各ベンダーが永続的にインストールされたOSのブートローダーをESPのパス\EFI\<vendor name>内に配置するという標準規則があるため、複数のUEFIブートローダーが同じESPに共存することが実際にサポートされ、ディスクごとに1つのマスターブートレコードを持つ従来のBIOSを使用するよりも簡単です。

/boot/grub/x86_64-efi/grub.efi：grub-installの一時ファイル

grub-installを使用すると、最初にgrub-mkimageユーティリティを使用してGRUBコアイメージを作成します。UEFIシステムでは、このファイルは、EFIにコピーされる前に/boot/grub/x86_64-efi/grub.efiまたは.../core.efiに保存されます。システムパーティションおよびgrub-installによってUEFI NVRAMブート設定に追加。 /boot/grub/x86_64-efi/*.efiのコピーはブートプロセスではまったく使用されませんが、ESPが何らかの理由で破損した場合に役立ちます。

注： Debian/Ubuntuでは、生成されたGRUBコアイメージには、/bootディレクトリが含まれているファイルシステムへのベイクインUUID参照が含まれるため、単にESPから/boot/grub/x86_64-efi/grub.efiまたはgrubx64.efiのコピーを作成し、それをリムーバブルメディアに移植します。これは、/bootファイルシステムの一意のUUIDを見つけようとするだけで、見つからない場合はレスキューモードにドロップしますそれ。私が正しく思い出せば、RedHat/CentOS/FedoraのGRUBは、リムーバブルメディアへの移植に適しています。

セキュアブート：shimx64.efiとその理由

セキュアブートでは、システムのセキュアブートNVRAM変数dbに含まれている証明書によってブートローダーが署名されている必要があります。 SHA256ハッシュは特定のブートローダーの特定のバージョンとのみ一致するため、ファームウェア変数も更新されない限り、更新はできません。だから証明書は行くべき道です。

残念ながら、多くのシステムベンダーは自社製品に少数のセキュアブート証明書のみを含めます。多くの場合、ベンダー独自の証明書（ファームウェアの更新とハードウェアデバッグ/ OEM構成ツール用）とMicrosoftのセキュアブート証明書のみです。一部のシステムでは、ファームウェア設定（= "BIOS設定"）を通じてセキュアブート証明書のリストを編集できますが、そうでないシステムもあります。したがって、独立したソリューションが必要でした。

マイクロソフトは、すべての人にUEFIブートローダー署名サービスを提供していますが、少なくとも最初は署名のターンアラウンドタイムが非常に長いため、GRUBのすべてのバージョンに直接署名する必要があるため、ブートローダーの更新に許容できない遅延が発生していました。この問題を解決するために、shimブートローダーが開発されました。これは、基本的に、1つ以上の証明書をセキュアブート承認済みリストに追加する最も単純で合理的なUEFIプログラムです。シンプルであることで、shim自体を更新する必要性を減らすことができれば幸いです。そのため、オープンソースOSディストリビューション（Linuxなど）は、Microsoftによって署名されたshimのバージョンを一度だけ取得してから、GRUBの任意のバージョンに署名できます。 _独自の証明書を使用します。その公開部分はシムに埋め込まれており、セキュアブートでディストリビューションのGRUBのバージョンを受け入れることができます。

5
telcoM