質問
8ディスクBtrfs RAID10ボリュームからArch Linuxから起動したマシンがあります。最近再起動しましたが、次のGRUB回復プロンプトが表示されました。
正確に何がこの仕事を引き起こしたのかはよくわかりません。最後の起動以降、少なくとも2つのアップデート（）をインストールし、pacman -SyuGRUBの再インストールを含むシステムに他の変更を加えた可能性があります。専用の起動ディスクを追加すると、システムを起動できます。
理論
#archlinux IRCチャンネルの役に立つメンバーと問題を解決しながら、偶然出会いました。Arch Wikiに関するこのメモ:
パーティションオフセット
core.imgをパーティションディスクに含めようとすると、オフセットの問題が発生する可能性があります。これは、grubのcore.imgがパーティション化されていないディスク（/ dev / sdXなど）のBtrfsプールに直接含まれることを意味します。 GRUBはBtrfsパーティションを起動できますが、モジュールは他のファイルシステムよりも大きくなる可能性があります。 grub-installで作成されたcore.imgファイルは、MBRと最初のパーティション間のドライブの最初の63セクタ（31.5KiB）に収まらない可能性があります。最新のパーティションツール（fdiskやgdiskなど）は、最初のパーティションを約1MiBまたは2MiBだけオフセットして、この問題を回避します。
これは、パーティションにGRUBをインストールする際に問題がある可能性があることを示しているようです。そしてパーティションのないディスク、最新のパーティションツールは、ディスクの先頭に余分なスペースを残してこれを軽減します（現在は）。
パーティションを分割したかパーティションを分割していないディスクにインストール
警告する:幼虫とても落胆パーティションブートセクタ、GRUB Legacy、Syslinuxなどのパーティションレスディスクにインストールします。この設定は、特にアップデート中に簡単に破損します。サポートしていないアーチ開発者が提供します。
まあ。
とにかく、grub-install -v出力に次の行を含めます。
grub-install: info: the total module size is 0xa07c.
上記の31.5KiB制限をはるかに超える約41Kですが、これが問題になる理由かどうか確信するほどGRUBをよく知りません。
質問
この場合はい問題は、それをどのように証明できるかということです。
grub-installもしそうなら、大声で失敗するのはどうでしょうか？後で起動可能なBtrfsディスクをフォーマットする正しい方法は何ですか？マスターブートレコード？一般的な技術？ - 専用ブートディスクが魅力的ですが、ボリューム上のすべてのデバイスに冗長ブートローダがあることをお勧めします。
btrfs replace各ディスクを消去して実行するよりも、各ディスクをパーティションテーブルに移行する方が良い方法はありますか？
ベストアンサー1
以前は、fdiskを使用してMBRパーティションテーブルを作成したとき、デフォルトでは最初の63セクタは変更されませんでした。ここにGRUBやその他のブートローダをインストールできます。
現代にすばやく進むと、同じツール（fdisk）を使用すると、GRUB2がBTRFSをサポートするstage1をインストールするのに十分なスペースが残ります。私はオフセットが業界で何を意味しているのか、基本的に約1MBだと思います。
なぜ失敗しなかったのかわかりませんが、grub-installブートセクタのサイズを確認しないようです。パーティションなしでどのように可能ですか？
冗長ブートローダの使用に問題はないと思います。手動で管理する必要がありますが、GRUB2のstage1は頻繁に変わりません。しかし、これはパーティショニングが必要であることを意味します。
パーティションテーブルを追加するためにディスクを移行するツールはありません。問題は、ファイルシステムがディスクのセクタに関連付けられており、パーティションテーブルを追加すると、そのセクタが変更されることです。 BTRFSファイルシステムがLVMにある場合、ファイルシステムは「仮想セクタ」にバインドされるため、ファイルシステムを移動できます。そうする必要があると言うのではなく、問題は何ですが、言及するのです。