Ubuntu 19 64ビットとWindows 10 64ビットをインストールしましたが、異なる場所に3つの異なるEFIファイルがあることがわかりました。
- EFI\boot\bootx64.efi
- EFI\ubuntu\grubx64.efi
- /boot/grub/x86_64-efi/grub.efi
これら3つのファイルの違いは何ですか？
ベストアンサー1
EFI\boot\bootx64.efi: 代替ブートローダパス
これは、既存のNVRAM起動設定なしで64ビットX86システムのUEFIファームウェアが探す唯一のブートローダパス名であるため、リムーバブルメディアで使用したいパス名です。
Windowsは自動的にこのパスにブートローダのコピーをインストールします。 GRUBをインストールするときgrub-install（またはgrub2-installLinuxディストリビューションによっては）、そのブートローダのコピーがまだ存在しない場合は、コマンドをここに配置することもできます。必要にgrub-install --removable応じて、代替ブートパスにインストールするように指示するか、代替パスgrub-install --force-extra-removableの既存のブートローダを上書きしてGRUBと置き換えることができます。
UEFI用のセキュアブート対応USBスティックを作成するには、shimのコピーとshimブートローダが探すEFI\boot\bootx64.efiGRUBのコピーを入れる必要があります。EFI\boot\grubx64.efigrubx64.efi shim ブートローダと同じディレクトリにあります。
永久にインストールされたオペレーティングシステムのブートローダパス
オペレーティングシステムがUEFIシステムに永久にインストールされると、クラシックBIOSにはまったく存在しない新しい手順が発生します。ブートローダがインストールされると、ファームウェア設定を保持するNVRAMメモリに4つのエントリが書き込まれます。
- ブートローダが格納されているESP（EFIシステムパーティション）のブートローダパス名
- ESPパーティションのGUID
- この特定のブートローダインスタンスを説明する（人になじみのある）名前
- オプションで、ブートローダに関する一部のデータ
Windowsの場合、Windowsブートプロセスの標準UEFIパス名は、\EFI\Microsoft\Boot\bootmgfw.efi説明を含む名前「Windowsブートマネージャ」です。オプションのデータには、WindowsブートローダのBCD構成ファイル内のエントリへのGUID参照が含まれているようです。
\EFI\Ubuntu\grubx64.efiUbuntuの場合、セキュアブートサポートが必要ない場合、またはセキュアブート\EFI\Ubuntu\shimx64.efiシムを使用している場合は、パス名は .説明的な名前は「ubuntu」にすぎず、オプションのデータは使用されません。
sudo efibootmgr -vUbuntuでは、Windowsのコマンドを使用してこれらのUEFI NVRAM起動設定を表示し、コマンドプロンプトを起動できます。管理者として次に、bcdedit /enum firmwareコマンドを使用して設定を確認します。
UEFI仕様には、各ベンダーが\EFI\<vendor name>ESPのパス内に永続的にインストールされているオペレーティングシステムのブートローダを配置する必要があるという標準的な規則があるため、複数のUEFIブートローダが実際に同じESPで共存するようにサポートされており、クラシックBIOSを使用するよりもマスターが優れています簡単です。各ディスクのブートレコード。
/boot/grub/x86_64-efi/grub.efi：一時ファイルgrub-install
を使用すると、ユーティリティをgrub-install最初に使用しますgrub-mkimageGRUBコアイメージ：UEFIシステムでは、このファイルは/boot/grub/x86_64-efi/grub.efiEFIシステムパーティションにコピーされ、UEFI NVRAM起動設定に追加される前に保存されます。このコピーは起動時にまったく使用されませんが、何らかの理由でESPが破損した場合に便利です。.../core.efigrub-install/boot/grub/x86_64-efi/*.efi
メモ:Debian / Ubuntuで作成されたGRUBコアイメージには、そのディレクトリを含むファイルシステムへの組み込みUUID参照が含まれているため、/bootESPからコピーしたりリムーバブルメディアに/boot/grub/x86_64-efi/grub.efi移植したりすることはできませんgrubx64.efi。/bootファイルシステム固有のUUIDが見つからない場合は、回復モードに入ります。私の記憶が正しい場合、RedHat / CentOS / FedoraのGRUBはリムーバブルメディアに移植するのに適しているはずです。
セキュアブート：shimx64.efiそしてその理由
Secure Bootを使用するには、システムのSecure Boot NVRAM変数に含まれる証明書でブートローダに署名する必要がありますdb。または、ブートローダのSHA256ハッシュを同じNVRAM変数にホワイトリストに登録する必要があります。 SHA256ハッシュは特定のブートローダの特定のバージョンとのみ一致するため、ファームウェア変数も更新しないと更新できません。したがって、証明書は出口です。
残念ながら、多くのシステムベンダーはその製品にいくつかのセキュアブート証明書しか含まれていません。通常、ベンダー独自の証明書（ファームウェアアップデートおよびハードウェアデバッグ/ OEM構成ツール用）とMicrosoftのセキュアブート証明書のみが含まれています。一部のシステムでは、ファームウェア設定（=「BIOS設定」）を使用してセキュアブート証明書のリストを編集できますが、他のシステムではそうではありません。したがって、スタンドアロンのソリューションが必要です。
マイクロソフトは誰にでもUEFIブートローダ署名サービスを提供しますが、少なくとも最初の署名にかかる時間がかなり長いため、各GRUBバージョンに直接署名する必要があるため、ブートローダの更新が許可されないほど遅延する可能性があります。この問題を解決するために、シムブートローダが開発されました。これは、デフォルトでセキュアブート承認リストに1つ以上の証明書を追加する最もシンプルで合理的なUEFIプログラムです。この単純さのおかげで、shim自体を更新する必要性が減ると期待されます。したがって、オープンソースのオペレーティングシステムディストリビューション（Linuxなど）は、Microsoftが署名したshimバージョンを一度だけ取得し、それ自体の証明書を使用してすべてのバージョンのshimに署名するだけです。 shimに公開部分を含むGRUBを使用し、セキュアブートでGRUBのリリースバージョンを許可します。