それぞれ 1 TB のディスクが 2 つあり、どちらも次のように作成された MD RAID-1 アレイのメンバーです。
mdadm --create /dev/md0 /dev/sda /dev/sde --level=1 --metadata=1.0
このパラメーターは、--metadata=1.0物理ディスクの末尾にある特定のMD RAIDヘッダーを使用するようにカーネルに指示します。
私がこの決定を下したのは、MD RAIDをサポートしていないUEFIでアレイのディスクを起動できる必要があるからです。したがって、UEFIの観点からディスクの先頭にあるように、すべてのメンバーディスクを選択して起動できます。 RAID設定の一部ではない通常のディスクと同様に、GPTパーティションテーブルを見つけます。
カーネルと initramfs は UEFI パーティションに一緒に配置されます。 UEFIはUEFIシステムで選択されたすべてのメンバーディスクからカーネルをロードし、UEFIはRAIDについて何も知りません。すべてのメンバーディスクが同じであるため（その上のRAID 1ミラーリングのおかげで）、これはすでに機能します。
MD RAID対応カーネルがロードされたら、RAIDメタデータ（ディスクの末尾にある場所）を読み込み、それを自動的に論理マッパーデバイスファイルに結合します/dev/md0。これ少し働く
現在、2つの質問があります。
質問1：カーネルは MD RAID アレイの存在を検出し、カーネルが MD RAID ヘッダを読み取っていることを証明します。
しかし、問題は、1つのメンバーディスクのみを表示し、他のメンバーディスクは表示しないことです。再起動時にシャッフルするディスクを選択すると、1つだけが表示されます。
論理的には、カーネルが他のディスクの1つのメタデータヘッダーを読み取らなかったため、そのヘッダーが存在するかどうかわからなかったことを意味します。たとえば、
mdadm --examine /dev/sda実際にRAIDメンバーであることを示しています（/dev/sdaこの再起動で不運なメンバーであると仮定）。不幸なディスクをアレイに追加しようとすると、ディスクはビジーとしてマークされ
mdadmました。また、残念ながら、ディスクはミラーリングされませんでした。たとえば、一部のファイルを編集して再起動時に表示し、再起動して別のファイルを表示すると、最後の再起動中に変更された内容は
/dev/sde表示されません。これはミラーリングがないことを示します。/dev/sda/dev/sde質問2：
fdisk /dev/md0説明するサポートGPTテーブルが破損しています。 GPT の場合、バックアップテーブルはディスクの末尾に存在します。その理由が何なのかわかりません。
fdisk最後に垣間見る物理ディスク/dev/sdaと/dev/sde？ （そうであれば）それらについてどうやって知ることができますか？最後に、/dev/md0物理メンバーディスクを抽象化する論理マッパーデバイスのみを提供しました。/dev/md0MD RAIDが入れるメタデータを減算する必要があるため、サイズも小さくなりそうです。物理ディスク。
質問：どうしたの？これら2つの問題を解決するには？
背景：私はGentoo Linuxの最新の安定版を使用しており、今週はsystemdとsystemd-boot（以前はGummiboot）を使って新しくインストールしました。
答え1
後で参考にするために、私の質問の下のコメントセクションにディスカッションの内容をまとめています。 （ありがとうございます。フロストスーツ）。
簡単に言うと：
- initramfsにRAIDをロードする場合：これは私がinitramfsを構築するために使用したものなので、RAIDなどの仮想デバイスをマウントする方法を知るために追加する必要があり
dracutます。デフォルトは次のとおりです（これが設定が機能しない理由です）。rd.auto=1/etc/kernel/cmdlinedracutrd.auto=0 - ESPの場合：RAIDを使用せずに2つの独立したESPパーティションを使用します。たとえば、
/boot別の物理ディスクにマウントします。次に、それらの間に独自のEPS同期を実装します。/boot_backup/dev/sdX1/dev/sdY1
これそしてそこにリンクは、Lennart PoetteringがSystemdがESPをチェックする追加のタスクを実行することを望み、システム管理者が自分が何をしているのかを知っていても（たとえば、ESPに競合するオペレーティングシステムがありません）、襲撃したときに書き込みを完全に行います。拒否したいことを示唆しています。--metadata=1.0UEFI システムが RAID1 であると考えないようにするには、このオプションを使用します。
その理由は、これらのRAID1設定によってオペレーティングシステムがESP全体をミラーリングし、他のオペレーティングシステムでも使用できるためです。他のオペレーティングシステムでは、このMD RAID（Linux関連）なしでESPパーティションに書き込むことができますが、個々のディスクに直接書き込むことができます。この場合、競合が発生する可能性があります。
このような設定がすべての人に適しているわけではありませんが、Systemdの使命が親システム管理者が自分が何をしているのかを知っている場合は、何をしたいのかわからない理由を理解していません。この子育ては、bootctl削除（またはに移動）する必要がある追加コードのようですmumctl。私はせいぜいbootctl警告のみを表示するか、少なくとも--forceオプションを許可する必要があると思います。その理由は、多くの場合、--metadata=1.0ESPでRAID1（MD RAID1など）を使用することが有益であるためです。
私の考えに最適な解決策は、RAIDなしで必要なユーザーのために複数のESPを更新するオプションを持つ設定ファイルをbootctl使用することです。systemd-boot-update.serviceこれにより、バックアップESPを使用できますが、ローカルオペレーティングシステムは、ESP全体ではなく、ESPの独自のエントリのみを同期します。しかし、市もこれに反対する。、理由がわかりません。
付録
これまで私がしたこと：
/boot、および/boot_primary。/boot_secondary/dev/sdX1/dev/sdY次に、プライマリユニットとセカンダリユニットにそれぞれおよびを取り付けますmount --rbind /boot_primary /boot。にも同様に追加してください/etc/fstab。- 埋めるために
/boot_primary走りましたbootctl install（emerge --config gentoo-kernelはい、私はカーネルの配布すでにインストールされてsys-kernel/installkernel-systemd-bootいるため、この2つのコマンドはデフォルトのESPを完全に埋めます。 - 塗りつぶし
/boot_secondary、再バインディング/boot、繰り返し。/boot_secondarybootctl install --efi-boot-option-description='Linux Boot Manager (Secondary)'emerge --config gentoo-kernel
今、2つの別々のESPがあります。上記の手順は手動で実行されますが、システムのインストール手順で一度だけ実行されます。
Makefileその後、後で更新するために、各アップデートの後に盲目的に4つの追加手順を実行するようにGentooアップデートシステム（これは1つのみ）を拡張しました。
/boot。に再インストールします。rbind/boot_secondarybootctl updateemerge --config gentoo-kernel- 再開されました。
/boot/boot_primary
最も速い解決策ではありませんが（Gentooのアップデートはとにかく遅いので、速度は重要ではありません。コンパイル、速度emergeなどのため）、私はその単純さと速度を圧倒しないという事実が好きです。アップストリームツール使用される特定の形式。したがって、アップストリームがその動作または形式を変更することを決定した場合、このコードを変更する必要はなく、常にアップストリームに追いつくことなくすべてが完全に機能します。 ESPを共有する別のOSをインストールしても、このコードは引き続き機能します。
emerge --config gentoo-kernelカーネルやモジュールが再コンパイルされず、ブートエントリを含むインストールだけが繰り返されるので、最も遅くはありません（ありがとう）カーネルの配布ギイ）。
エラーが発生したときに/dev/sdXルートパーティションは/まだ機能し（RAIDのおかげで）、セカンダリESPを使用してシステムをシームレスに起動できました。 ESP 修復ツールを手動で操作する必要はなくなりました。