Grub：ブートディレクトリではなくMBR部分のみをインストールしますか？

GRUBがMBRから起動するときに起動プロセスの開始時に実行する必要がある既存のBIOS互換性ステップの数は、MBRの実際のコードのみをロードできることを意味します。ディスクブロック対応するLBA番号は、インストール時にMBRコードにパッチされます。このブロックは通常最初のブロックです。GRUBコアイメージ。これには、より多くのブロックをロードするコードと、残りのGRUBコアイメージがある場所を定義するブロック番号のリストが含まれています。

MBRパーティションディスクでは、通常、MBRと最初のパーティションの先頭の間に未使用のスペースがあります。 MS-DOSの場合、元のルールは、次のディスクトラックの先頭から最初のパーティションを開始することでした。これは通常、MBRを含む最初のパーティションの前に少なくとも63のディスクブロックを意味します。最新のシステムでは、最初のMBRパーティションは、内部で512ワードより大きいブロックサイズを使用できるディスク、SSD、およびSANストレージシステムの照合を最適化するために、ディスクの先頭から正確に1MiBのブロック＃2048にさらに一般的に配置されます。 。 。

したがって、MBRパーティションディスクでは、ディスクの先頭は通常次のように配置されます。

• ブロック＃0：MBR
• ブロック＃1：ブロックリストを含むGRUBコアイメージの最初のブロック
• ブロック #2...#n: GRUB コアイメージの残りの部分
• ブロック＃2048：最初のパーティションの始まり。

GRUBコアイメージは、所定のブロック番号に従って完全にロードされます。 GRUBは、GRUBコアイメージが完全にロードされ抽出されるまで、パーティションテーブルまたはあらゆる種類のファイルシステムについては不明です。

GPTパーティションディスクでは、ブロック＃0のすぐ次のブロックはGPTパーティションテーブルによって占められるため、GRUBコアイメージは「BIOSブートパーティション」に含まれます。これは、MBRに含まれるブロック番号が1ではなく、BIOSブートパーティションの最初のブロック番号とコアイメージに属する残りのブロックの番号が同様に移動することを意味します。したがって、BIOSスタイルGRUBを使用するGPTパーティションディスクでは、BIOSブートパーティションがディスクの最初のパーティションであると仮定すると、物理レイアウトは次のようになります。

• ブロック＃0：GPT保護MBR、内蔵GRUB MBRコード
• ブロック #1...#(x-1): 実際の G​​PT パーティションテーブル
• ブロック＃x：GRUBコアイメージの最初のブロックとブロックリストを含むBIOSブートパーティションの最初のブロック。
• ブロック#(x+1)...#(x+n): GRUB コアイメージの残りの部分

それでもGRUBリカバリモードに入ることができるという事実は、BIOSブートパーティションを削除したと言っていましたが、削除しなかったことを示します。書くそのブロック、BIOSブートパーティションが占めるスペースがパーティション間に割り当てられていないスペース、またはサイズ変更された他のパーティションで使用されていないスペースである可能性がありますが、それでも古いものがあり、GRUBはまだブロックをロードしてコアイメージを見つけますできます。ただし、これらのブロックを上書きしないように保護する特別な方法はありません。これが発生すると、何らかの理由でGRUBコアイメージが破損し、GRUBは回復モードに入ることはできません。

GRUBコアイメージの内容

GRUBコアイメージには次の項目が含まれています。

• GRUBカーネル：技術的にこれはGRUB回復モードに入るのに必要な唯一の部分です。
• GRUB構成ファイルとGRUBモジュールディレクトリを保持するディスク、パーティション、およびディレクトリを表すために含まれる初期GRUBルートパス。 Linux では、Linux システムが正常に稼働している場合、通常は/boot/grub/grub.cfgそれぞれと表示されます。/boot/grub/i386-pc
• 最初のGRUBルートパスで参照されるパーティションに使用されるパーティションテーブルとファイルシステムの種類を読み取って理解するためのコードを少なくとも含む組み込みGRUBモジュールのセット。コアイメージは63未満のディスクブロックを収容する必要があるため、このモジュールセットは通常MBRシステムでできるだけ小さく保たれます。
• オプションで組み込みGRUB構成ファイル1 つ以上の GRUB コマンドの使用
• memdiskSYSLINUXブートローダツールファミリで使用されるイメージに似たオプションの内蔵ディスクイメージ
• （オプション）セキュリティ用（およびGRUB UEFIバージョンのセキュアブート許可要件を満たすため）、他のGRUBモジュールおよびオペレーティングシステムカーネルに署名するために使用されるGPG公開鍵

これらはすべてサイズを最小限に抑えるためにLZMA圧縮されているため、手動で簡単に読み取ったり変更したりすることはできません。

現在、リカバリモードになっていてパーティションを一覧表示できないため、GRUBコアイメージにpart_gpt.modGPT（）用のパーティションモジュールは含まれていますが、MBR（part_msdos.mod）用のパーティションモジュールは含まれていないことを示します。 MBRパーティションモジュールがないと、/boot/grub/i386-pcGRUBコアイメージにファイルシステムドライバモジュールが含まれていても、ディレクトリを含むパーティションにアクセスできません。したがって、GRUBはnormal.mod回復モードをオーバーライドできるプログラムをロードできません。

今やるべきこと

• GRUBコアイメージを安全な場所（以前はGPTパーティションテーブルの構造が占めていたMBRと最初のパーティションの先頭の間のスペース）に再構築する必要があるかもしれません。 BIOSブートパーティションが削除されたため、現在の場所は安全ではありません。後で別のパーティションに再割り当てされ、警告なしで上書きされる可能性があります。
• GRUBコアイメージを再構築するときは、ここに含まれているGPTパーティションモジュールをMBRパーティションモジュールと交換する必要があります。すべてのコンポーネントは圧縮されていない形式（または同様のディレクトリ）で存在する必要があるため、/usr/lib/grub/i386-pc最も簡単な方法はすべての圧縮されていない適切なコンポーネントをインポートして新しいコアイメージを構築して圧縮することです。以前のバージョンを解凍して修正することは、単に苦労する価値がありません。元のGRUBを最初からインストールしたときに使用したコードを再利用するときに別のコードを書くのはなぜですか？
• GRUBコアイメージの位置が変わる可能性が高いため、MBRコードも書き直す必要があります。
• このコマンドは、GRUBモジュールと他のGRUBモジュールが新しいGRUBコアイメージと同じバージョンであることをgrub-install確認する必要があります。もちろん、既存のファイルをコアイメージを再構築するために使用されたファイルセットと比較することはできますが、...既存のGRUBインストールルーチンを使用して既存のアイテムを上書きするだけで、なぜ他のファイルで気にするのですか？コードの作成とデバッグはうまくいきますか？normal.mod/boot/grub/i386-pc/boot/grub/i386-pc

すべてのGRUBコンポーネントの圧縮されていない合計サイズは、i386-pc確かに4MiB未満です。何もない。すでに存在する場合、書き込みサイクル数が非常に制限されている古い第1世代PATA SSDなどの特別なものを使用しない限り、書き換えを避けるように努力する価値はありません。

デフォルトのUEFIはこれをどのように実行しますか？

UEFIファームウェア標準にはFAT32ファイルシステムのサポートが含まれているため、GRUBブートローダのデフォルトのUEFIバージョンは、必要なすべてのgrubx64.efiモジュールを含む単一のファイルにパッケージ化できます。含む normal.modあなたがしたい場合。通常のファイルとしてロードされます。固定ディスク位置でブロック番号や内蔵コードを操作する必要はありません。