/bootに行き、grubを更新して新しい場所/boot/grub2/i386-pc/{core,boot}.imgを見つける方法

GRUBレガシーとGRUB2という用語を混同しています。 「stage2」という用語は、GRUB Legacy（バージョン0.9xなど）にのみ適用されます。しかし、どういう意味なのかは分かりそうです。

これらのファイルは、GRUBバージョンがMBRにインストールされ、MBRと最初のパーティションの間に間隔がある場合、または実際の起動プロセスではなくi386-pcBIOSブートパーティションにインストールされている場合/boot/grub2/i386-pc/{core,boot}.imgにのみ使用されます。grub2-install

i386-pcGRUBアーキテクチャのオペレーティングシステムには、起動時にBIOSが最後にディスクシーケンスを確認した方法に関する情報を取得する信頼できる方法がないため、BIOSディスクサポート（一般的な方法）に依存するように設定されている場合、デフォルトではgrub-install2つの利用可能なオプションがあります。あります。

• ファイルが提供されたら、/boot/grub[2]/device.mapその中の情報を使用してオペレーティングシステムデバイスをGRUBデバイス名にマップします（これはBIOSディスク番号と直接一致します）。
• このdevice.mapファイルが利用できない場合は、現在のオペレーティングシステムのディスク順序がBIOSディスクの検出順序と同じであると推測してください。この推測は正確であってもなくてもよい。

（具体的には、USBでインストーラまたはライブメディアを実行すると、USBストレージデバイスは通常最初の「ディスク」として検出されます。これにより、インストールされているオペレーティングシステムが自己起動するとUSBgrub-installストレージのBIOSレベルディスクエミュレーションが機能しなくなります。ないので、推測は必要ありません。BIOSは現在USBメディアから起動しないためです。

実際のMBRブロックに含まれるGRUBブートコードには、2つの情報が同時に記録されますgrub-install。ブートドライブ文字とGRUBが次に読み取る必要があるLBAブロック番号。最新バージョンのGRUBでは、ドライブ文字は通常、0xff「MBRの読み取りに使用されたのと同じディスクBIOSを使用する」という意味でエンコードされています。

MBRパーティションディスクでは、LBAブロック番号は通常0x0000000000000001MBRと最初のパーティションの間の間隔を表します。 MBRに分割されたディスクには、残りのGRUBコアイメージ、基本モジュール、プレフィックス文字列（ディレクトリの場所を指す/boot/grub）が含まれます。 GPTでパーティション化されたディスクでは、これらすべてがパーティションに書き込まれます。bios-boot実際のMBRブートコードに含まれるLBAブロック番号は、パーティションの先頭を指すため、より高くなりますbios-boot。

埋め込みコードの最初のブロックには、次に読み取るブロックを識別するブロックのリストが含まれています。 MBRパーティションディスクに含まれる場合、これはLBAブロック＃2で始まる一連の連続ブロックになります。このシリーズの長さは、主にGRUBコアイメージに組み込まれている基本モジュールの数と種類によって異なります。ほとんどの埋め込みコードはLZMA圧縮後にReed-Solomonエラー修正コードを使用して保護されているため、これを修正すると通常はコード全体を本質的に書き直す必要があります。残念ながら、ディレクトリの場所を識別するプレフィックス文字列は/boot/grub[2]明らかに圧縮されたセクション内にあります。

最新のシステムでは、MBRと最初のパーティションの開始との間の間隔は、通常、最初のパーティションをディスクの1MiBに合わせるために正確に2047ブロックです。しかし、以前のシステムは、照合に気にしないバージョンを使用してパーティションを分割した可能性があり、fdisk代わりにディスクトラックの先頭にパーティションの先頭を配置してDOS互換性を維持しようとしました（クラシックC / H / Sディスクは、幾何学は長い間ディスクファームウェアによって維持される架空のものであり、そのような場合、MBRと最初のパーティションの最初の部分との間のギャップがはるかに小さくなる可能性があるため、組み込みgrub-installコードのサイズを最小にするためにコアイメージ一緒に最小の基本的なGRUBモジュールの数を組み込む必要があります。GRUB ドキュメントをご覧ください：i386-pcこれに関連して、「厳しく制限されたプラットフォーム」とみなされます。

MBRベースのディスクの単純なRedHat / Debianインストールでは、/bootディスクの最初のパーティションとは別のパーティションとして一般的な組み込みモジュールのセットは次のとおりです。

• biosdisk.modディスクアクセスにBIOS機能を使用する
• part_msdos.modMBRパーティションテーブルについて
• /bootパーティションをサポートするファイルシステムに必要なすべてのモジュール

少なくとも（/bootパーティションがext2ファイルシステムで初期化されている場合）、ext2ファイルシステムをサポートするために必要なGRUBモジュールはおよびext2.modですfshelp.mod。これは、最新のGRUBアーキテクチャで達成できる最小の組み込みコードサイズの1つにつながる実用的な構成ですi386-pc。

/grubGRUBディレクトリが別々のファイルシステムに名前が付けられ、ディスクの最初のパーティションである場合、埋め込まれ/bootた/bootプレフィックス文字列は通常(,msdos1)/grubGRUBディスク識別子が欠落していることに注意してください。これは、「BIOSを使用して同じディスクからMBRを読み取る」を意味します。 。msdos1ディスクの最初のMBRスタイルのパーティションを表し、単に/grubファイルシステムのルートから始まるディレクトリパスです。/boot/grub/boot

したがって、MBR間隔またはBIOSブートパーティションに含まれるコードのみを使用して、GRUBはBIOSを使用してnormal.modディスク(,msdos1)/grub/i386-pc/normal.modサポートおよびファイルシステムメタデータを読み取って正しいブロックを見つけることができます。その後、設定ファイルを別々に読みます(,msdos1)/grub/grub.cfg。

たとえば、GRUBコアイメージを含むGRUBはAHCI SATAコントローラに直接アクセスし、UUIDを介して正しいパーティション/ファイルシステムを識別できますが、サイズが3倍を超えるため、ヒットイメージのサイズが大きくなるahci.mod可能性があります。制限されます。search_fs_uuid.modahci.modbiosdisk.mod

/ bootの場所が変更されたときにmbr / bios-bootパーティションのブートローダコードを更新する正しい方法は何ですか？

唯一の実用的な答えは「組み込みブートローダコードを再実行して書き直すgrub[2]-install」です。これを行うときに必要に応じて、システム構成に適したコンテンツを含むファイルを新しくインストールしたことを/boot確認してください。/boot/boot/grub/device.mapする次の開始時。

DebianやUbuntu、Mintなどの派生製品では、パッケージ管理システムはGRUBバージョンがインストールされているターゲットデバイスを覚えていますi386-pc。を使用してこの情報を表示し、を使用してsudo debconf-show grub-pc更新できますsudo dpkg-reconfigure grub-pc。

RedHatのパッケージには同様の機能がないようです。

RedHatとその派生製品は組み込みのブートコードをアップグレードしません。

比較のため、GRUB アーキテクチャには通常、x86_64-efi挿入を防ぐサイズ制限はありません。利用可能なすべてのGRUBモジュールgrubx64.efiセキュアブート用に署名でき、アドインを実装するために実行コードをロードする必要がないUEFIバイナリを生成します。実際には、ディレクトリが完全に破壊されてもシステムが読み取れる限り、すべてのgrubx64.efiGRUBノーマルモードコマンドライン機能を使用できることを保証します。/boot/grub[2]