Grub2MBRとWindowsMBR

Question

VistaがインストールされたHPシステムと、非表示の復元パーティションがあります。その後、Win7（32ビット）Ultimateにアップグレードし、そこからWin7Proにアップグレードしました。現在、ハードドライブに障害が発生しています。 Win7パーティションのフリーザーベースのリカバリの準備のために氷上に置く前に、partimageを使用してリカバリパーティションを（エラーなしで）取得することができました。

別のドライブに、3つのプライマリパーティションと1つの拡張パーティションを作成しました。

リカバリパーティション（NTFS）
Win7パーティション（NTFS）
Ubuntuルート（ext4）
Ubuntuスワップ（ext4）（論理パーティション）

次に、Ubuntu 10.4をインストールし、grub2にMBRのインストールを許可しました。次に、partimageを使用して、障害が発生したドライブから取り出したイメージをリカバリパーティションに追加しました。ここで、Win7パーティションを回復する前に、既存の回復パーティションにアクセスできることを確認したいと思います。そして、私はできません。ファイルは表示されますが、起動できません。 GrubはそれをWindowsパーティションと見なし、メニューに一覧表示します。しかし、それを起動しようとすると、カーソルが点滅している空白の画面を見つめます。 gpartedを使用してgrubをバイパスし、リカバリパーティションをアクティブにして、grubの代わりに直接起動しようとしましたが、それでもgrubで起動します。

それで、そのような背景で、私に質問をさせてください。

私が理解しているように、標準のIBM/WIndows MBRコードは、パーティションテーブルでアクティブ/ブート可能フラグが設定された最初のプライマリパーティションを探し、そのパーティションの先頭にあるコード、つまり「パーティションブート」に制御を移します。レコード」（PBR）。次に、PBRはNTLDR/BOOTMGR/grub/etcを見つけて、ロードします。私の理解は正しいですか？
ブートプロセスのどこで、リカバリパーティションを起動するための割り込みキー（HPの場合はf11）が処理されますか？ MBR？ PBR？ブートマネージャー/ローダー？
GrubがMBRを書き込むとき、トラック0の残りも使用しているように見え、MBRコードはこのコードを実行してから、ロードされているパーティション（私の場合はパーティション3）に残りのgrubコードをロードします。この意味で、パーティションテーブルのアクティブ/ブート可能フラグは無視されます。私はこれを正しく理解しましたか？

リカバリパーティションをロードできないため、ここでいくつかの部分が明らかに欠落しています。 grubの「chainloader」（なぜ+1？）コマンドはPBRコードを実行するだけだと思います。これが本当なら、私のリカバリパーティションの何かがホースで止められています。

Billy ONeal · Answer

このようなリカバリパーティションがあるシステムでは、通常、アクティブなパーティションがリカバリパーティションです。リカバリパーティションには「PressF11」メッセージが表示され、押されていない場合はメインOSパーティションに転送されます。

MBRは本質的に馬鹿げています。パーティションの1つを選択し、そのパーティションのVBRに転送するだけです。

Linux/Windowsのデュアルブートが必要な場合は、リカバリパーティションをGRUBパーティションに転送する必要があります。これにより、オプションが許可され、Windowsが選択された場合はWindowsに転送されます。

リカバリパーティションで時間を無駄にすることはありません。HPのWebサイトからすべてのドライバを入手できます。ボックスにすでに7が入っている場合は、Vistaに戻したいということには同意できないと思います。

だから、あなたの特定の質問に。

はい、あなたの理解は正しいです
上で答えた
MBRにインストールしたときにGRUBが何をするのか、具体的にはわかりません。私の理解では、ビジネスロジックは実際にはそこにありませんでしたが、間違っている可能性があります。

お役に立てば幸いです:)

Neal · Answer

質問3：はい、grubはそれ自体の一部をトラック0に配置します。個人的にgrubをmbrに配置することはありません。常に「通常の」mbrを使用し、grubをプライマリパーティションにインストールします。

使用済みとしてマークされていないディスクの一部を使用すると問題が発生するかどうかは、状況によって異なります。 Windows Vistaおよび7のディスクパーティショナーは以前のバージョンとは動作が異なると思いますが、トラック0のスペアパーツを利用しているかどうかはわかりません。

最近、プログラムの試用版（Adobeの何か？）がディスクのその領域に書き込み、grubの一部を上書きするために問題が発生していると聞きました（試用版を何度も再インストールするのを防ぐためだと思います）。（詳細については、Ubuntu UKポッドキャストの最近のエピソードを聞いてください）私の見解では、自分のものではない領域に書き込む場合、他の人がまったく同じことをしていることに文句を言うことはできません。

Grubのmbrビットは、それ自体の次のステージの物理ディスクアドレスを独自のコードに書き込み、アクティブかどうかに関係なく、パーティションをまったく認識しません。

Ken · Answer

MBR（1セクター、512バイト）には、ブートコードとパーティションテーブルが含まれています。「デフォルト」のMBRコードは、アクティブなプライマリパーティションを見つけ、チェーンがそれをロードします。（GRUBの用語では、+ 1は最初のセクター、つまりそのパーティションのブートセクターを意味します。）

GRUBをMBRにインストールすると、デフォルトのMBRコードが置き換えられ（もちろんパーティションテーブルは保持されます）、代わりに残りのGRUBコアイメージが読み込まれます）、「MBRギャップ」（MBRセクターの後に続く最初の「トラック」のおそらく未使用の部分）にインストールされます。GRUBをパーティションにインストールすると、次のようにインストールされます。ブートセクター。デフォルトのMBRコードチェーンは、GRUBブートセクターをロードします。

そのため、常にGRUB-MBRのコードが変更されて実行されています。fixmbrのバリエーションを使用してデフォルトのMBRコードを復元できます。。

しかし、せいぜい、それはリカバリパーティションのイメージが良好であり、VanillaMBRを介してアクセスできることを証明するだけです。実際、リカバリパーティションのイメージが悪いことを証明した場合、それがGRUBを介して機能しなかった理由である可能性があり、それが良ければ機能したはずです。あなたが良いコピーを作ることができれば、それはより良いかもしれません。

奇妙な理由で、リカバリパーティションがGRUBを介して起動しない可能性があります。工場出荷時の元のMBRには、リカバリパーティションの前提条件である特別なソースが含まれていた可能性があります。私はそれらを持っていたシステムを避けてきたので、そこでは多くの洞察を提供することができません。