web-dev-qa-db-ja.com

どのUEFI実行可能ファイルが自動検出されますか？

EFIのこの驚異的な概要 によると、UEFIエントリには次の3つのタイプがあります。

  • Compatibility-bootは、BIOSが行ったように、ディスクの先頭にあるものをすべて起動します
  • Native-bootは、明示的なパスからEFI実行可能ファイルを起動します
  • Fallback-bootは、さまざまなデフォルトの場所（アーキテクチャ、/EFI/BOOT/BOOTx64.efi、/EFI/BOOT/BOOTaa64.efiなどに基づく）からEFI実行可能ファイルを起動します。

これはすべて理にかなっていますが、OS（この場合はCentOS）からEFIシステムパーティションを見ると、さらに多くの.efiファイルがあります。

+--EFI
|  +--boot
|  |  +--BOOTAA64.EFI
|  |  \--fallback.efi
|  +--centos
|  |  +--gcdaa64.efi
|  |  +--grubaa64.efi
|  |  +--MokManager.efi
|  |  +--shim-centos.efi
|  |  \--shim.efi

さらに、ブートマネージャは/EFI/centos/shim.efiをブートするオプションのみをリストします。このCentOSディスクは別のコンピューターからのものであるため、このマシンのファームウェアにはshim.efiの明示的なエントリが追加されていません。

なぜこれほど多くの.efiファイルがあるのですか？

ブートマネージャーはどのようにしてshim.efiを見つけましたか？

ブートマネージャが他のすべての.efiファイルを見つけられなかったのはなぜですか？

この質問 は似ていますが、フォールバックとネイティブブートの違いについてです。

bootuefifirmware
1
Dan

なぜこれほど多くの.efiファイルがあるのですか？

これらのファイルのほとんどはサポートファイルです。たとえば、MokManagerは、コンピューターが認識するセキュアブートキーの数を拡張するためにShimが使用するマシン所有者キー（MOK）を管理するためのツールです。 MokManagerは通常、Shimがデフォルトの後続ブートローダー（通常はGRUB）を起動できない場合に呼び出されます。 EFI/centosに少なくとも2つのShimのコピー（shim.efiとshim-centos.efi）があるようですが、EFI/boot/BOOTAA64.EFIはおそらくShimの3番目のコピーです。 EFI/centosが冗長である可能性があります。おそらく、別の名前を使用したか、誤って作成した以前のインストールから残っています。

Linux開発者は、問題や特殊なケースの問題を回避するために、新しいEFIプログラムファイルを作成する習慣も身に付けています。たとえば、インストールでは、EFI/centosディレクトリにGRUBの2つのコピーが表示されます-grubaa64.efiとgcdaa64.efiは、構成ファイルとサポートファイルを探す場所を除いて同一です（ このスタックを参照）質問と回答を交換してください この問題についてもう少し詳しく説明します。）

ブートマネージャーはどのようにしてshim.efiを見つけましたか？

あなたはすでに（部分的に）その質問に答えています-あなたが「ネイティブブート」と呼んだものでは、コンピュータはブートローダーへのパスをNVRAM変数に保存します。最近のほとんどのLinuxディストリビューションはデフォルトでShimを使用しているため、NVRAM変数はShimバイナリを指します。 Shimが起動すると、ファームウェアに登録され、後続のブートローダー（通常はGRUB）が起動します。

ブートマネージャーが他のすべての.efiファイルを見つけられなかったのはなぜですか？

標準のEFIブートマネージャーは、フォールバックファイル名と、一部のEFIではMicrosoftのブートローダーを除いて、.efiファイルをアクティブにスキャンしません。 （ネットワークブートエントリや組み込みEFIシェルのエントリなど、場合によってはブートリストに追加される可能性のあるものもあります。）

代わりに、ほとんどのEFIは、ブートローダーのインストールプロセスの一部としてブートローダーを登録するためにOSインストーラーに依存しています。したがって、CentOSはShim、GRUB、および関連する.efiバイナリをESPに書き込み、それらを指す1つ以上のNVRAMエントリを追加します。理論的には、OSは10、100、1000、またはそれ以上の.efiファイルをESPに保存し、そのうちの1つだけを登録できます。再起動してキーストロークを押すと、 EFIブートマネージャーには、OSインストーラーが追加したエントリが1つだけ表示されます。ほとんどのLinuxディストリビューションでは、efibootmgrツールを使用してこれらのエントリを追加、削除、または編集できます。

AFAIK、EFIブートローダーをアクティブにスキャンする唯一のツールは次のとおりです。

  • rEFIt-この古いブートマネージャーは主にMacで使用されていましたが、UEFIベースのPCでも使用できます。 EFIのほとんどのサブディレクトリ（つまり、EFI/centos/、EFI/BOOT/など）でブートローダーをアクティブにスキャンしますが、EFI/tools/は注目に値する例外です。 rEFItはもはや維持されていないことに注意してください。
  • rEFInd-これはrEFItの更新されたフォークであり、rEFItのアクティブスキャンアルゴリズムを継承していますが、いくつかの調整が加えられていますLinuxでより適切に機能し、冗長またはその他の不要なブートエントリを明示的にトリミングします。したがって、rEFIndは.efiバイナリとLinuxカーネルの両方を表示します（ EFIスタブローダー のおかげで、ほとんどの場合、EFIプログラムファイルです）。
  • GRUB 2の構成スクリプト-GRUB 2に依存するディストリビューションには、通常、.efiファイルをスキャンして追加するスクリプトが付属していますGRUBメニューに移動します。rEFItやrEFIndとは異なり、これらのスキャンは、起動時ではなく、Linux（または他のホストOS）の実行時に発生します。

これらのツールはいずれも、EFI独自のブートマネージャーメニューに表示される内容に影響を与えないことに注意してください。それらはすべて、独自のメニューに表示されるものに影響を与えますが、それ以上のことはありません。理論的には、他のツールがそのようなスキャンを実行する可能性があります。 EFI could起動のたびに、またはユーザーからのコマンドで、そのようなスキャンを実行しますが、実際には、実行するものはありません。 AFAIK、すべてのEFIは、関連するNVRAMエントリを持つ独自のブートマネージャーに依存しています。 （一部はバグがあり、NVRAMエントリの信頼性が低いため、フォールバックファイル名を使用することが実際に必要です。）

3
Rod Smith