/boot/それが何であるか、実際に何であるかを理解しやすい説明を見つけるのは/boot/efi/少し難しいです。
私はテストとインターネット検索でいくつかの可能な答えを見つけましたが、経験豊富な誰かが私の発見/考え方に挑戦または確認してくれたことをとても嬉しく思います。
コンテキスト：
- マザーボードのCSM（互換性サポートモジュール）がオフになっています。
- マザーボードでは、クイックブートとセキュアブートの両方がオフになっています。
- オペレーティングシステムはUbuntu Server 22.04です。
- インストーラは同じ容量の2つのディスクを使用します（RAID 1の場合）。
- どちらのディスクもGPT形式で、両方のディスクのEFIシステムパーティションはパーティション番号
1とサイズ512MB（1もちろんタイプも）です。 /ソフトウェアRAID 1を使用して作成されますmdadm。- より広範囲にわたって：ソフトウェアRAIDがどのように機能するか、将来の可能性があるRAID "バグ"（障害のあるディスクの交換、ディスクの1つだけの起動など）の処理方法をよりよく理解するために、いくつかのテストを行っています。 。
私が見つけたもの（上記の背景に基づいて）/質問
1.）観察：/bootEFIシステムパーティションではありません。つまり、ブートローダは含まれていません。
ただし、これにはGRUB構成ファイルが含まれています（/boot/grub/私の場合）。
両方のディスク（Ubuntu Serverインストーラを使用）にブートローダをインストールし、grub設定ファイルを変更し（「仮想」フラグを追加し/etc/default/grubて実行します）、サーバをシャットダウンしてそのドライブを物理的に削除してテストしました。 EFIパーティションは次のとおりです。変更するとすでにマウントされています）。サーバーが起動しましたが、オペレーティングシステムが指定されたEFIパーティションを持つドライブを見つけることができなかったため、「パニック」モードで停止しました（Ubuntuサーバーインストーラは、削除したドライブのUUIDを使用してマウントポイントを追加しました）。intel_iommu=onupdate-grub/etc/fstab
しかし、cat /proc/cmdline した表示がintel_iommu=on指定されました。
これにより、グラブ構成はEFIパーティションに保存されず、システムをインストールしたときに作成されたソフトウェアRAIDの一部であると考えられます。
2.）観察：インストールさ/boot/efiれたブートローダにアクセスできるEFIシステムパーティションのマウントポイント。
ドライブの少なくとも1つにブートローダを取り付ける必要があります（ここにマウントされているEFIシステムパーティションに）。それ以外の場合、システムは起動しません。
ブートローダ（GRUB）はを実行して再インストールできますgrub-install /dev/sd{x}。
3.）[1.と2.が本当に本当なら]、質問：Ubuntuオペレーティングシステムを実行するにはEFIシステムパーティションをマウントする必要がありますか？
中のインストール手順を省略できますか/etc/fstab？
これは単に好奇心からの質問です。
答え1
はい、mountを省略できますが/boot/efi...
EFIシステムパーティションの行をコメントアウトする/etc/fstabと、システムはまだ正常に起動します。
ただし、他の変更を行わない限り、実際のブートローダ（設定だけでなく）へのすべての更新は失敗します。つまり、apt update grub-*そのアップデートがリリースされるとバグが発生します。追加の手順を最初に実行しないと、grub-installGRUBの再インストールも失敗します。
実際に/boot/efiは目的のためにインストールされていません。オペレーティングシステムの起動：Linuxカーネルが起動し始めると、EFIシステムパーティションは起動プロセスの一部を完了しました。代わりに、インストールの主な目的は次のとおりです。アップデートでブートローダを有効にする。 2番目の目的は、システム管理者が簡単にアクセスできるようにすることです。ESPの秘密を明らかにするとESPは通常のファイルシステムのようにバックアップできます。。
一部のディストリビューション（Gentoo？）は、Microsoft Windowsがそれを処理する方法と同様に、ブートローダまたはその構成が実際に更新されたときにのみEFIシステムパーティションをマウントすることを選択すると思います。ただし、ほとんどの主要なディストリビューションでは、ESPを通常のファイルシステムのようにインストールすることを選択します。
（あなたの観察＃1と＃2は完全に正確であり、明白な問題は含まれていません。あなたの観察＃3にのみ実際の問題が含まれているので、これは私の答えです。）
答え2
ブートパーティションはほとんどの目的で使用されなくなりました。暗号化、LVM、さまざまなファイルシステム、RAIDなどの高度な概念を理解していないliloなどのミニマリストブートローダに必要です。したがって、解決策は、liloが理解できる単純なパーティションにカーネルとinitrdを配置し、initrdのスクリプトがLinux環境でメインリポジトリの複雑な初期化を実行することです。 grubはよりスマートなので、ほとんどの現在のgrub設定ではこれを必要としませんが、レガシーは残ります。
その後、基本的に同じ動機を持ち、ESPが登場しました。つまり、さまざまなオペレーティングシステムの高度な機能を気にせず、オペレーティングシステムから独立した単純なファームウェアを持つようにすることです。これには、オペレーティングシステムを起動するために必要なすべてを含む標準化された構造を持つ単純なパーティションが必要です。 ESPは、最新のオペレーティングシステムに依存しないブートパーティションと考えることができます。
たとえば、専用の起動なしでESPを使用できます。カーネル、initramfs、およびブートローダをその中に入れるか（「ブートとESPを組み合わせる」）、EFIスタブとinitramfsが組み込まれたカーネルイメージを持ちます。この場合、ESPに単一のファイルを入れるだけです（いいえ専用のブートローダ）。私は長い間私のラップトップにこの設定を使用してきました。
1つの注意：ESPは、オペレーティングシステムによって提供されるソフトウェアRAIDの一部にすることはできません。 UEFI仕様にはソフトウェアRAIDへの言及はありません。これは前の段落の結果と見なすことができますが、liloはより簡単でこれを処理できます。 LinuxのRAID1メタデータにはデバイスの末尾にスーパーブロックがあるため、liloの場合、RAID1ブートパーティションのサイズは少し小さいようです。デバイスは小さなファイルシステムであり、UEFIファームウェアが仕様内で同じように動作することを要求するものではありません。マイクロソフトはこのような単純な構造でRAID1を作成することに失敗したので（下、「ソフトウェアRAID」を作ってみるとどういう意味か分かるでしょう）、仕様からソフトウェアRAIDを完全に省略した可能性が高くなります。
ソフトウェアRAID1を使用した冗長ブートの一般的なアプローチは、2つの異なるディスクに2つの独立したESPを置き、手動で同期し、2つのファームウェアブートレコード（各レコードから起動できる機能を含む）を持つことです。これらの設定の例には、ZFSソフトウェアRAIDにインストールされているProxmox VEがあります。この場合、systemd-boot EFIブートローダ（つまりgrubではない）を使用し、起動関連のコンテンツが更新されるたびにスクリプトがESPを同期します。これは2つのESPを作成する私が知っている唯一の自動インストーラです。パーティションを作成します。これらのESPは互いのイメージではないため、FAT UUIDは異なる場合があります。私はそれをマウントしてファイルをコピーしました。 ESPのアップデートは次のとおりです。非常に珍しい。