efiパーティションがマウントされるのはなぜですか？

Ubuntuおよびその他のいくつかのディストリビューションでは、EFIパーティションはにマウントされてい/boot/efiます。

私が理解しているように、EFIパーティションはOSのrootfs（/）の前に読み込まれます。カーネルがロードされてマウントされた後、/EFIパーティションはまだ何のために必要ですか？理論的には、最初のインストール後/boot/efiは、.efiバイナリのみが含まれているため、アクセスする必要はありません...

では、なぜマウントされているのですか？頻繁にアクセスしない機密ファイルを含むパーティションを自動マウントすることは、設計の観点から見るとあまり賢明ではありません...

編集：

最近のシステムにはgrub.cfg、efiパーティションが含まれている場合があります。これは私の16.04LTSには当てはまりませんが、このバグレポートを参照してください。したがって、ESPに構成ファイルがあるシステムでは、マウントする方が理にかなっています。それでも、どのくらいの頻度でを実行する必要update-grubがあり、スクリプトがそれをマウントして、更新後に再びマウントできなかったのでしょうか。

さまざまな状況でESPにアクセスする必要があるいくつかの理由があります。

• /boot/efi/EFI/ubuntu/grubx64.efi -これはEFI GRUB 2バイナリであり、GRUBパッケージが更新された場合は置き換える必要があります。
• /boot/efi/EFI/ubuntu/grub.cfg-これは、ほとんど機能しないGRUB構成ファイルです。主にロードします/boot/grub/grub.cfg。このリダイレクトは、セキュアブートシステムの「フック」を有効にするために行われます。セキュアブートを使用しない場合、grubx64.efiバイナリをローカルでビルドして直接を指すことができます/boot/grub/grub.cfg。ただし、場所は/boot/grub/grub.cfgESPによってシステムごとに異なるgrub.cfgため、grubx64.efiローカルでの構築が許可されていないセキュアブートにはESPにファイルを配置する必要があります。私見では、メインgrub.cfgおよびその他のGRUBサポートファイルをESP に配置する方が理にかなっていますが、これを担当する開発者は、BIOSベースのシステムの動作に比べて、より保守的なアプローチを選択しています。とにかく、grub.cfgESPで更新されることはほとんどありません。しかし、いつか、特にGRUB Debianパッケージが更新された場合には、それが必要になるかもしれません。
• /boot/efi/EFI/ubuntu/shimx64.efi-これは、セキュアブートが機能するために必要なShimバイナリです。GRUB 2バイナリのように、Debianパッケージの更新によって更新される可能性がありますが、パッケージの更新shim-signedです。
• /boot/efi/EFI/ubuntu/MokManager.efi-これは、ShimサポートツールであるMokManagerバイナリです。Shimのように、パッケージの更新で更新される可能性があります。
• /boot/efi/EFI/ubuntu/fwupx64.efi-これは、EFIベースのコンピューターでのファームウェアの更新の自動化を支援するツールです。前述のEFIバイナリと同様に、Debianパッケージの更新によって更新される可能性があります。
• EFIファームウェアファイル-ファームウェアを更新するには、ファームウェアファイルをESPにコピーする必要があります。これは手動のプロセスか、Linux fwupdateバイナリを使用してfwupx64.efiEFIバイナリを一致させることで少なくとも部分的に自動化されたものである可能性があります。（ただし、後者がESPへのファイルの書き込みを必要とすることを100％肯定するわけではありません。これは非常に新しく、現時点では最小限のドキュメントしかありません。）
• その他のEFI関連ツール-rEFIndブートマネージャーやその他の非標準のEFIブートマネージャーやツールなどのプログラムをESPにインストールする必要がある場合があります。インストールする必要のあるツールの数は膨大ですが、それらのほとんどは新しいものであり、影響を受けるシステムの数はわずかです。
• 手動構成ファイルの調整-ブートローダーを再構成する場合は、ESPで構成ファイルを読み取り、編集して、編集したファイルを保存して戻す必要があります。さらに言えば、単に構成を調べるには、ESPがマウントされている必要があります（読み取り専用マウントの場合もあります）。
• システム情報ツール- ブート情報スクリプトなどのツールは、システムの構成方法に関するレポートを生成するために、ESPの構成ファイルを読み取ります。ブート情報スクリプトは、ESPがマウントされていない場合でも、ESPをマウントして動作する可能性がありますが、100％肯定的ではありません。ESPがすでにマウントされていることを前提とする他のツールが存在する可能性があり、この前提が満たされない場合、それらの機能は低下します。

つまり、OS自体や、ESPからの読み取りまたはESPへの書き込みが必要または必要になる可能性があるのには、かなりの数の理由があります。とはいえ、これらの理由は数が少ないため、ESPを一時的にマウントし、完了時にアンマウントするメカニズムが有益な場合があります。たとえば、ESPの構成ファイルを変更する自動化ツールのように、Debianパッケージのインストールスクリプトがその仕事をすることができます。ただし、私の知る限り、ESPのマウントステータスの変更はまだ予定されていません。

ESPはデフォルトでかなり制限された権限でマウントされることに注意してください。最近（15.10または16.04以降、たぶん-正確にはいつなのかわからない）、マウント権限が変更され、からのみroot読み取ることができるようになりました/boot/efi。それ以前でもroot、読み取り権限は緩やかでしたが、ESPへの書き込みのみが可能でした。rootはパーティションをマウントできるので、この時点でESPをマウント解除したままにしておくとセキュリティ上のメリットは最小限になりますが、バグや電源障害などが原因でファイルシステムがESPに損傷するリスクが少なくなるというメリットがあります。

あなたは正しい：/boot/efiデフォルトのセットアップでESPをマウントする必要はありません（別名grub 2で）

ESPがマウントされていない場合にgrubの構成が問題なく更新さgrub.cfgれる/boot/grubようにするためのupdate-grub更新。

私は以前のインストールで数年間それを問題なくマウントしていませんでした。

必要に応じてマウントしないことで、ブート中にマイクロ秒を稼ぐことができます;-)