MBRバックアップの勘違い

 よく、HDDが起動できなくなったときのためにddでブートセクタを保存しておこうと言う記事があるけど、それで勘違いされていることが多いみたい。 P2Vをしていた人が、rsyncでフルコピーしてブートセクタをddでコピーしたけど動かない!と言うんで見に行ったら、MBRを勘違いしていた。

 よくあるサイトの説明で、

でMBRをバックアップ!って書いてあるんだけど、これってパーティションテーブルもバックアップしている。
 MBRタイプディスク先端の構造は、純粋なブートローダー(MBL)は446バイトまでで、そこからパーティションテーブルが入って512バイトになる。 MBRはブートレコードだけど、ブートローダーと同意では無いわけだ。
 だから、完全にパーティション構造が同じ場合には512バイトを書き戻しして良いんだけど、セクタ数が異なる環境に複製した場合にはこれは通用しなくて、書き戻しは446バイトにしないといけない。
 だけど、この人は、512バイトがブートローダーだと思っていて、

を実行していた。

 今回の場合rsyncに丸1日以上かけたらしいんで、最初からやり直すのは忍びないので、fdiskでパーティションテーブルを切り直す。
 CentOSのインストールディスクで起動してlinux rescueを起動、検出は当然うまくいかない(パーティションテーブルが間違ってるから)んで、削除するかの問いにNo!して、シェルに落ちてfdiskを起動。
 パーティションを全部削除して、作業前に作ったのと同じ手順でパーティションを切り直して保存( fdiskはこの先頭447バイト目から512バイト目までのテーブルのみを書き換えるので、パーティションを削除して、正しいパーティション情報で作り直せば正しくパーティションが読めるようになる)
 あとは、念のためGRUBも入れ直しておくんで、確認がてら再起動して再度linux rescueに入る。 今度はLinuxインストールが確認できるはず(だめならfdisk操作に誤りがある)
 で、うまくいっていれば/mnt/sysimageにルートパーティションがマウントされているはずだから、chrootしてgrub-installしてやる↓

 これで再起動してやれば起動できるようになっている。

 GPTについては、MBR部分に単一のパーティションが有るという情報が入っているため状況によっては問題にならないことも有る(MBRの次の位置にGPTのヘッダが有って、GPTのシステムタイプは0xFFであると定義されているから、どんなパーティションを切ったとしてもGPTは先頭が512バイトの位置にあるから差異が発生しない)が、基本的にはブートローダーを複製する場合は先頭から446バイトとするのが良いと思う。

(1212)


カテゴリー: LAMP[Linux, Apache, MySQL, PHP]   パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です