web-dev-qa-db-ja.com

grub2が実際にMBRをインストールしたドライブを確認する方法は？

私は、Squeezeアップグレードの一部としてgrub2にアップグレードされたDebian/Squeezeシステム（少なくともWoodyまでの歴史を持つ）を使用しています。すべて正常に動作しますが、ディスク構成をいじくりまわすところです。

現在、マシンは、RAID1化された/、/ homeおよび/ bootパーティションを備えた2つの80GBドライブで実行されます（誰かがスワップがどこにあるのか疑問に思った場合に備えて、RAID1化された「/データ」といくつかのスワップを備えた別のドライブのペアがあります。 、しかし私はそれらに触れていません）。

私は2つの130GB SSDを追加し、それらを少なくとも80GBドライブのパーティションと同じ大きさにパーティション分割し、RAID1を拡張してそれらを含め、新しいSSDドライブに切り替え、同期を待って、古いSSDを削除するつもりです。 SSDだけが残されるようにアレイからドライブします（ファイルシステムを拡張します）。しかし、mdadm/ext3のラングリングは、この質問に関するものではありません...

これで、マシンから削除したい古い2つの80GB（IDE）ドライブが残ります。私の心配は、それらを削除すると、いくつかの重要なMBRが使用されることです。マシンが起動可能であることを確認するにはどうすればよいですか？

すなわち：

  • Squeezeのアップグレードを行ったとき、grub2をインストールするドライブについていくつかの選択肢があったことを覚えています（デフォルトではすべてのドライブでした）。 SSDは当時はマシンにありませんでした。これを再実行してgrubをSSD MBRにインストールする方法を教えてください。 （私はそれがいくつかのパッケージのdpkg-reconfigureだと思います）。

  • インストールされているとgrub2が判断したドライブを見つけるにはどうすればよいですか？最近の/ boot/grub /の下にはほぼ200個のファイルがあります。どこを見ますか？また、/ boot/grub/device.map.autoが現在3つのドライブのみをリストするのは少し奇妙に思われます（80GBのうち2つですが、他のドライブペアの1つだけで、SSDはありません）。どうすれば最新の状態にできますか？ （pdate：それは赤いニシンでした; device.map.autoは数年前からの遺物であるようです; device.mapはgrub-mkdevicemapによる更新で賢明に見えました。この領域の私のパラノイアは起源だと思いますGRUB）で見られるデバイスの順序を並べ替える古いmoboのBIOSから。

結果：すべてが順調に進み、2つの古い80GB IDEドライブをそのまま使用できるようになりました。すべてのファイルシステムは新しいパーティションサイズにサイズ変更されました。私が探していたもう1つの「Grubパズルの欠けている部分」はdpkg-reconfigure grub-pcこれは、MBRを維持するディスクを要求します。アーロンの答えは実際、これが期待通りに機能していることを私に安心させ、それゆえその答えを受け入れるために最も多く行いました。

debianbootgrub2bootable
18
timday

MBRは512バイトなので、GRUBが存在するかどうかをすばやく確認できます...

dd if=/dev/sda bs=512 count=1 | xxd

これはMBRをダンプします。私の場合、「GRUB」はバイト0x17F = 383にあります。

dd if=/dev/sda bs=1 count=4 skip=383

そうすると、「GRUB」が出力され、その後にddが出力されます。

これをbash forループまたは何かにラップして、より多くのドライブにまたがることができます。手動で実行したくない場合。

17
Aaron D. Marasco

ブートプロセスにはいくつかのステップがあります（私は従来のPC BIOSについて説明しています）。

  1. BIOSは、ブートディスクの最初のセクター（512バイト）を読み取ります。
  2. この最初のセクターのコードは、BIOSインターフェイスを介して、固定された場所でさらにデータとコードを読み取ります。このBIOSインターフェースは2つのハードディスクのみを公開します。ディスク0は最初のセクターが読み取られた場所であり、ディスク1は2つ以上あると簡単に予測できない別のディスクです。ブートセクターには、追加のデータが存在するハードディスクを示すバイトが含まれています。これは/boot/grubを含むディスクです。
  3. 前の段階でロードされたコードは、パーティション、ファイルシステム、およびその他の高レベルの概念を理解します。データには、(hd0)/boot/grubおよびその他のGrubモジュールの検索場所を決定するファイルシステムの場所（つまり、grub.cfgのような文字列）が含まれます。
  4. grub.cfgが実行され、通常はメニューを表示してOSを起動します。

ブートセクタはgrub-setupによって生成され、通常はgrub-installを通じて呼び出されます。ブートセクターは、grub-installまたはgrub-setupコマンドラインで（Linux構文で）指定したディスクで終了します。 file -s /dev/sdaを実行すると、ディスクにブートセクターがあることを確認できます。新しいディスクを追加していて、そこから起動したいので、新しいディスクでgrub-installを実行する必要があります。同じディスク上でgrub-installを複数回実行しても無害です。

難しい部分は、上記のステップ2です。可能な場合は、Grub（つまり/boot/grubディレクトリ）をBIOSブートディスクに配置します（または、反対方向からこれに近づくと、BIOSに/boot/grubがあるディスクからブートするように指示します）。これがdevice.mapの出番です。 (hd0)が/boot/grubを含むディスクにマップされていることを確認してから、そのディスクでgrub-installを実行します。

2つのディスクがソフトウェアRAID-1構成の場合、同一のブートセクターになります。これは望ましい動作です。BIOSブートディスクである1つのディスクに障害が発生しても、もう1つのディスクからのブートは機能します（同じ場所に同じバイトが含まれているため）。特定のパーティションのみをミラーリングした場合、ブートセクターのインストールは1つのディスクにのみ影響します。 grub-installを変更してdevice.mapを(hd0)の2番目のミラーコピーを含むディスクに関連付けるように変更した後、2番目のディスクで/boot/grubを再度実行する必要があります。

ステップ3はかなり複雑ですが、通常はそのまま使用できます。手順4では、GrubがUUIDでファイルシステムを検索したり、名前付きファイルを検索したりするため、ディスクを指定するさまざまな方法を心配する必要がなくなります。

16
Gilles 'SO- stop being evil'