• ベストアンサー
  • 困ってます

MBRを復旧してもパーティションが見えない

Windows と Linux が混在している HDD の Windows の部分のみ(リカバリ領域も含めて)をバックアップしようと思い 作業する中で遭遇したトラブルについての質問です。 まず、/media/linux-backup/ でマウントされているUSBに dd if=/dev/sda of=/media/linux-backup/MBR--2014-04-10.bu bs=512 count=1 とやって MBR を保存し、 fsarchiver で Linux の各パーティションをセーブした後に、 Linux のパーティションを全て削除し、 clonezilla で HDD 全体のバックアップイメージを取りました。 その後、 dd if=/media/linux-backup/MBR--2014-04-10.bu of=/dev/sda bs=512 count=1 とやってまずは MBR を復旧できたと思ったのですが、 Linux の各パーティションの存在が gParted で見えません。 再起動してみても、 やはり gParted でパーティションが見えない状態です。 一つの方法としては HDD の現在空き領域になっている部分でパーティションを切り直して、例えば sda10 などの番号を 元々その目的の Linuxディストリビューション が入っていたパーティションの番号と 一致するようにさえしておけば (sda10 が HDD 上で実際に存在する位置が CHS の情報として以前とは異なっていても) fsarchiver でリストアして、 その後に問題なくそのパーティションから起動・操作できるだろうとは思います。 (gPartedでパーティションを移動させるのと同じなので) ただ、なるべく以前と(CHSが)完全に一致するパーティションの配置を復旧する方法を知りたいです。 どなたか原因と対策がお分かりになる方は ご教授下さい。 よろしくお願いします。

noname#197334
noname#197334

共感・応援の気持ちを伝えよう!

  • Linux系OS
  • 回答数8
  • 閲覧数1667
  • ありがとう数16

質問者が選んだベストアンサー

  • ベストアンサー
  • 回答No.7
  • yakan9
  • ベストアンサー率54% (2122/3925)

> ここはよく分からないです。 > Windows7(リカバリ領域も含めて)のみが存在する状態の MBR のバックアップを取って、 > 後にそのWindows7(リカバリ領域も含めて)のみが存在する状態へと > dd if=/media/linux-backup/MBR--2014-04-10.bu of=/dev/sda bs=512 count=1 > と打つことによって戻したいのならば、 > というお話なのでしょうか。 その通りです。 > まず、/media/linux-backup/ でマウントされているUSBに > dd if=/dev/sda of=/media/linux-backup/MBR--2014-04-10.bu bs=512 count=1 > とやって MBR を保存し、 この状態の詳細が記載されていないので、分かりませんが、 CD/DVD-ROM起動の状態、USB接続USBメモリ起動の状態であれば、Linuxをまだ内蔵HDDにインストールしていないと言うことを言われていれば、その場合は、正しいと思います。 > その内蔵HDDの Windows7(リカバリ領域も含めて)が占拠している以外の部分を > 一つの大きな拡張パーティションとし、 > その中をいくつかの論理パーティションに区切って > Debian,Mintなどをインストールしておりました。 この記載で、GPTではなく、MBR構成であり、Windows 7 であることが当方には見えてきた訳です。 MBR上には、起動に必要な、ブートストラップルーチンがあり、これは、最後にインストールしたLinuxが書き込んだものだと思えます。 もしこの状態のMBRを保存しようとしていれば、その起動のための必要なエントリは、最後にインストールしたLinuxの、 /boot/grub/grub.cfg をポイントしているはずです。 よって、Windows 7だけにして起動させるためには、既にブートストラップルーチンは、Windows 7のものではないということです。 そこで、MBRを保存していたものを書き込んだだけではいけないことが分かります。 少なくとも、これに加えて、Windows RE等で、 コマンドプロンプトに入り、 bootrec /fixboot bootrec /fixmbr を入れる操作が必要になるということです。 本当に保存したものだけで立ち上げたい場合は、Windows 7 だけで起動できるような、MBRのブートストラップルーチンはWindows 7 の物でないとダメだということを言いたかった訳です。 それは、Linuxをインストールする前の状態を保存しないといけません。 Linuxをインストールする前、すなわち拡張パーティションを作っただけの状態のMBRを保存していればよいと思います。 ただし、基本パーティション3個と拡張パーティション1個の状態であれば、 MBRのパーティションテーブルには、4エントリ分しかないため拡張パーティションの中の論理パーティションの情報まで格納するスペースはないため、拡張パーティションのPBRに追加保存されると思われます。 ただ、ここでLinux用の論理パーティションの削除や新規作成していくとどんな影響が出るのかまでは不明です。 物理デバイス名(sda1,sda2,等)が、拡張パーティションの中だけで削除や新規作成されている分には問題は発生しないと思えますね。 この4エントリ分のMBRのパーティションテーブルの状態次第だと思います。 こうした条件の詳細が質問文からは全く見えなかったです。 まだ、この基本パーティションが何個か、は見えませんけど。 GPTでなければ、 Linuxの端末で、 fdisk -l で、パーティションの設定は簡単に見えるでしょうけど。 fdiskコマンドは、GPTに対応していない場合に、gpartedをよく使います。 fdisk -l でMBRの場合は十分でしょう。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

たびたびのご回答ありがとうございます。 yakan9 さんが書いておられたことが やっと理解出来始めた気がしました。 私は知識が不足しておりますために どれくらい書いておけば十分ということが正確に判断できない部分がありますので、 どうぞご容赦下さい。 MBR のバックアップは Clonezilla でのバックアップ作業を始める直前、 つまり様々な Linux ディストリをインストールし終わった後の状態で おそらくは HDD 上にインストールされた Debian から バックアップを取ったのですが、 (Linux がまだ一つもインストールされていない状態での MBR のバックアップ もあったと思いますが、使っておりません) なぜこうしたかということを書いておりませんでした。 (これは書いとかないといけませんでした) MBR の中にはどのパーティションがどこの番地で始まりどの番地で終わるという情報が入っているはずなので、 Windows のパーティションしかない状態にした後でも Linux の各パーティションは削除の操作をしただけでそのパーティションの中身を全くイジッていない場合は MBR さえ復旧すれば 全てのパーティションの存在が元通りになり、 ブートプロセスにおいて MBR の次に必要な情報が入っている パーティションのたとえば PBR などの適切な場所を読みに行き、 さらに次に必要な情報がある場合はそれをまた適切な場所に読みに行く・・・・・ というようなプロセスがきちんと行われてくれるようになり、 元々 HDD 上にあった全ての Linux OS も起動可能な状態へと回復できるかもしれない、 と思ったからでした。 しかし、よく考えるとこの考えはやはり甘かったようです。 gParted で Linux の各パーティションに削除の操作をすると そのパーティションが存在する HDD 上の場所に書き込まれている内容、 特に PBR あたりの中身が削除の前とは微妙に違ってきている可能性が高いですね。 16進数ダンプしてみると分かるのでしょうけど Linux をインストールする時にマウントポイントという項目がありますが、 / を私はいつも選んでいまして、特に不具合などはなかったようなので これでいいのだろうと思っておりました。 ここで例えば多くのファイルを置く可能性が高い /Desktop を含む /home あたりを別パーティションに分離すると その OS のメインのパーティションの容量が節約できるのでしょうが、 普段のその Linux OS の動作速度はほとんど変わらないだろうと思い、 試してみたことがありません。 /boot を別パーティションに分離しておいた場合は、 その OS のメインのパーティションをフォーマットしてしまっても 他のパーティションの OS を問題なく起動できる、 というメリットがあるのですね。 インストール済みのそれぞれのディストリで調べてみても /boot の容量は 20MB から 40MB 程度でしたから この方式にしてみるのも良さそうです。 HDD の構成は Gparted で見ると(fdisk -l ではラベル名がでない) sda1 fat16 DELLUTILITY sda2 ntfs Recovery sda3 ntfs OS sda4 拡張パーティション sda4 の中に論理パーティションが多数 という風になっております。 DELLUTILITY パーティションのことは 今回のことに関係がないはずと思い書いておりませんでした。 今回のようなバックアップの取り方をした理由ですが、 たとえば、/media/ext3-data/ でマウントされている空のパーティションがあります。 空のはずですが、ファイルマネージャで見ると lost+found というフォルダ(そのままでは削除できない)があるので $ sudo chmod 777 -R /media/ext3-data/ $ sudo rm -r /media/ext3-data/lost+found/ $ ls -l /media/ 合計 977564 drwxrwxrwx 2 root root 4096 5月 1 15:26 ext3-data ほか多数・・・ $ sudo ls -l /media/ext3-data/ 合計 0 の操作の後に このパーティションをファイルマネージャのプロパティから見ても 合計 52.8 GB 使用中 2.9 GB とかなりの容量を意味不明に食っているわけでして、 こういったパーティションの存在そのものを残したまま HDD 全体のバックアップを取ると容量が余計に必要になってしまう、 と思い今回のようなやり方でバックアップを取ったわけです。 今回バックアップを取った Windows のみのイメージは 念のために時々はバックアップしておこうくらいのノリで作ったものですので、 そのうち実際に使う場合は Windows PE のディスクは作っておりますので、 これで bootrec /fixboot bootrec /fixmbr と打って起動可能にするということでもいいかもしれません。

その他の回答 (7)

  • 回答No.8
  • yakan9
  • ベストアンサー率54% (2122/3925)

回答番号7の「お礼」の記載ありがとうございます。 よく理解して貰えて記載して良かったです。 1. > /boot > を別パーティションに分離しておいた場合は、 > その OS のメインのパーティションをフォーマットしてしまっても > 他のパーティションの OS を問題なく起動できる、 > というメリットがあるのですね。 この理解は正しいです。 付け加えると、この/bootパーティションの定義により、LVM構成を採らない様になるためデバッグしやすくなります。 2. > /boot の容量は 20MB から 40MB 程度でしたから > この方式にしてみるのも良さそうです。 これは単なるミステイクでしょうが、Ubuntuはもう少し大きいと思います。 3. >  Windows PE のディスクは作っておりますので、 > これで > bootrec /fixboot > bootrec /fixmbr > と打って起動可能にするということでもいいかもしれません。 ただ、これは、一方的に成功するかどうかは、当方は保証できないことを記載しておきます。 理由は、MBRのパーティションテーブルの変動により、上記コマンドの仕様が不明なため、正確な検証をしていない当方としては、「不明」と言うことにさせていただきます。 最後に当方の説明で9割方理解したことをわざわざ記載して頂いたことに感謝します。 このくらい理解できる人は、初心者と記載してはいけません。 初心者と記載することは、非常にマイナス面も多いことを理解してください。 分かりやすく説明するため、専門用語を極力使用しないようにしている場合、専門知識の取得ができないといったことが上げられます。 初心者と言う「甘え」の枠に入っている間は、一人前になりたくないと言っているようなもので、次回からは止めましよう。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

たびたびのレス、誠にありがとうございます。 > 最後に当方の説明で9割方理解したことをわざわざ記載して頂いたことに感謝します。 いえいえ、感謝しなければいけないのはこちらの方なのですから、 そうおっしゃられると恐縮です。 Windows PE のコマンドにつきましては、 実際にそれをする機会が訪れたときに(場合によっては訪れないかも) これが一発で成功しなかった場合に時間をかけて試行錯誤するのが面倒だと思った場合は、 やはり今回のように Mint を空き領域に便宜的にインストールして Windows を Grub から起動可能な状態にするのが手っとり早いです。 Mint の LiveUSB を起動してから10分ちょいくらい操作して後は放ったらかしておけば、 そのうち Windows が起動可能な状態になります。 > > /boot の容量は 20MB から 40MB 程度でしたから > > この方式にしてみるのも良さそうです。 > これは単なるミステイクでしょうが、Ubuntuはもう少し大きいと思います。 Debian,Mint ではそれくらいの数字で正しいです。 Ubuntu は最近は使わなくなりましたが、 別マシンの内蔵HDD上にまだあった Lubuntu で見てみると確かに 230MB くらいでした。 このサイトで回答を書き込んで下さる方は プロのエンジニアと思われる方も多いようですので、 そういう方達に比べると自分はまだまだ初心者だな、 と思っていたわけです。 こういうサイトで「初心者」と書いた場合は、 確かに意味合いが違って来てしまいますね。 yakan9 さんのおっしゃる通り、 これからは初心者と書くのはやめることにいたします。 アドバイスありがとうございました。

  • 回答No.6
  • yakan9
  • ベストアンサー率54% (2122/3925)

> ただ、なるべく以前と(CHSが)完全に一致するパーティションの配置を復旧する方法を知りたいです。 これは、パーティションを削除したり、新規作成をしないことで防ぐしかありません。 理由は、sda1を削除すれば、以前のsda2が、sda1になってしまうことで分かると思います。 そこで、一旦パーティションを作ったものは、削除せずに修正という形でフォマットしてインストールすると良いと思います。 すなわち、当方の場合は、 Linux1用、 /boot / swap Linux2用、 /boot / swap Linux3用、 /boot / swap このように定義しておき、各パーティションは削除せずに、修復してフォマットするだけにすれば、sdaxの"x"は、変化しないし、パーティション情報も狂わないですみます。 Linux1には何をインストールしたとメモだけ取ればよいと思います。 /boot は、サイズ200MB / は、サイズ20GB swap は、搭載メモリ+ 1GB といったサイズを当方は設定しています。 新規作成する分は、問題ないです。 よって削除しないようにするだけです。 これが、質問の全ての不具合を作り出しているのかも知れません。 すなわち、パーティション情報のズレがおかしくしているとも言えると思われます。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ご回答ありがとうございます。 追加の内容をNo.7 の欄にまとめて書き込んでおきます。

  • 回答No.5
  • yakan9
  • ベストアンサー率54% (2122/3925)

> すみません、書き漏らしておりました。 > clonezilla で HDD 全体のバックアップイメージを取ったというのは、 > Windows のみを復旧したくなった時に使うためですので、 > Linux のパーティションを全て gParted で削除した後です。 前提条件がWindows(? XP 7 8)であれば、ddコマンドで保存するタイミンクが遅いと思いますが。 Linuxをインストールする前の、grub ブートストラップルーチンがMBR(場合によっては、GPTの構成の場合) に書き出される前の状態を保存すべきなのではないかと思います。 ただし、貴殿のLinuxのインストールの条件が何も記載されていないため、正確な回答はできないと思います。 貴殿のこれまでの質問をチェックすると、 VMware と VirtualBox の相互比較 http://okwave.jp/qa/q8470032.html などでも変わるのではないかと思います。 > その後、 > dd if=/media/linux-backup/MBR--2014-04-10.bu of=/dev/sda bs=512 count=1 > とやってまずは MBR を復旧できたと思ったのですが、 この保存したMBR(GPTの場合は少し異なります)の戻し方の詳細が記載されていないのが、気になります。 通常、戻すときは、CD/DVD-ROMからの起動で、ddコマンドを出さないと無視されることは、経験していれば分かることなのですが、このことの詳細が気になります。 すなわち、内蔵HDD(sdaと言うデバイス名からの起動のLinuxから) ddコマンドを出していれば、このddコマンドは無視されています。 こうした質問は、正確な内容でないと、正確な回答はできないことを理解して欲しいと思います。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

こちらの方も以前からお世話いただいたことのある方ですね。 本当にありがとうございます。 > 前提条件がWindows(? XP 7 ][8)であれば、ddコマンドで保存するタイミンクが遅いと思いますが。 > Linuxをインストールする前の、grub ブートストラップルーチンが > MBR(場合によっては、GPTの構成の場合) に書き出される前の状態を > 保存すべきなのではないかと思います。 ここはよく分からないです。 Windows7(リカバリ領域も含めて)のみが存在する状態の MBR のバックアップを取って、 後にそのWindows7(リカバリ領域も含めて)のみが存在する状態へと dd if=/media/linux-backup/MBR--2014-04-10.bu of=/dev/sda bs=512 count=1 と打つことによって戻したいのならば、 というお話なのでしょうか。 > 貴殿のこれまでの質問をチェックすると、 > VMware と VirtualBox の相互比較 > http://okwave.jp/qa/q8470032.html > などでも変わるのではないかと思います。 ここの意味は仮想環境の元で Linux を動かしているかもしれない、ということでしょうか。 結局この質問の後、仮想環境はまだ使っておりません。 Linux ディストリビューション群は PC の電源投入時に LiveDVD を起動させて、直接 HDD にインストールしました。 私は初心者ですので、 Linuxのインストールの条件というのが、 仮想環境を使うかどうかの他にどういうことがありうるのかが いまいち分かりません。 OSセレクタとして Grub でなく MBM、Acronis OS Selector、LBシステムコマンダー あたりを使っているかもしれない、ということでしょうか。 私は LinuxMint,Debian などでデフォルトでインストールしてくれる Grub しか使えません。 内蔵HDDは一つのみ存在しておりまして、 その内蔵HDDの Windows7(リカバリ領域も含めて)が占拠している以外の部分を 一つの大きな拡張パーティションとし、 その中をいくつかの論理パーティションに区切って Debian,Mintなどをインストールしておりました。 以下の内容が正確に伝わらなかったのかな、と思ったのですが、 今回やりたかったことは、 この内蔵HDDをWindows(リカバリ領域も含めて)のみしか存在しない状態にしたものの Gzipバックアップイメージをまずとりまして、 その後に、この内蔵HDDを元通りの Debian,Mintなども存在しマルチブートできる状態へ復元したかったわけです。 Clonezilla で HDD 全体のバックアップイメージを取るときは MBR も自動的にバックアップしてくれるので、 MBR も自動的にバックアップしなくても大丈夫です。 既に間違いなく伝わっておりましたら、 この段落は読み流しておいて下さい。 「MBR(GPTの場合は少し異なります)の戻し方の詳細」 につきましては、 No.2 の方へのお礼の欄に書き込みましたように USB にインストールした Debian を使っている、 というくらいのことでよろしいでしょうか。

  • 回答No.4
  • kteds
  • ベストアンサー率41% (1800/4290)

No.2の内容には影響ありませんが、2か所訂正です。 --- 誤り:「て」が余分。 厳しい条件は満たしてていません。 訂正後: 厳しい条件は満たしていません。 --- 誤り:「r」は不要。 grub2ブート情報(grub.cfrg)が再編成されますので、 訂正後: grub2ブート情報(grub.cfg)が再編成されますので、 --- 以上です。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ご回答ありがとうございます。

  • 回答No.3
  • vaidurya
  • ベストアンサー率45% (2713/5982)

MBRの保存と書き戻しは手順どおりのはずなので それ以外の操作か、ハードウェアやファームウェアの不具合に問題がありそうに見えます。 たとえば dd if=/dev/sda bs=512 count=1 | od -h > hd.dump cat /media/linux-backup/MBR--2014-04-10.bu | od -h > bu.dump して、二つの16進ダンプを比較してみるとどうでしょう? (ddでofは指定せず、パイプでodコマンドに受け渡し、odの出力をファイルに保存) ddの処理が、正常に行われていれば これは同じになるはずです。 万が一、これが同じにならないなら、ddの実行ファイルが壊れているか… HDD自体か、HDDのファームウェア、HDDコントローラーなどのどこかに 異常がおきていると考えることができます。 BIOSのMBR保護機能で起きることもあるのかもしれません。 実際、うちではAdaptecの1430SAとサムスンの500GB HDDの組み合わせで パーティションテーブルが正常に書き込まれないという現象を経験したことがあります。 mdadmでRAID5の一基として組み込み、RAID5が正常稼働した状態から 再起動すると、パーティションテーブルが消滅し RAIDがデグレード、パーティションを作りなおして、addしてrebuildして 再起動してみたら、やっぱり消滅x2で、愛想つかしました。 RAID0なんか組んでたら、壊滅していたところです(笑) 現象は、パーティションテーブルがキャッシュされているために 保存されていない情報が機能していたんじゃないかと思いますが 当時は、パーティションテーブルをダンプしてみるところまで考えがまわりませんでした。 余談ですが、Gpartedでパーティションを認識しても、ファイルシステムが不明となるのは FAT32やNTFSであれば、パーティションIDから決め打ちができるのに対して Linux用としてID:83にしたパーティションは、ext2,3,4,xfs他、何か特定できないためです。 ただしddでパーティションテーブルを書き戻しても、既存のパーティションが残っていれば PBRの情報から、ファイルシステムの判別までが行われるようです。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

以前から、様々な質問でお世話になりまして、本当にありがとうございます。 > dd if=/dev/sda bs=512 count=1 | od -h > hd.dump > cat /media/linux-backup/MBR--2014-04-10.bu | od -h > bu.dump この手順で生成された二つのファイルを diff で比較しても、 ちゃんと同じでした。 ddの実行ファイルは正常に機能しているようです。 なぜ、Gparted で Windows のパーティションしか存在しないように 表示されるのかさっぱり分かりません。 残りの詳しい経過は No.2 の方の欄に書き込んでおります。

  • 回答No.2
  • kteds
  • ベストアンサー率41% (1800/4290)

No.1の補足です。 Versionが何も書いてありませんのでWindowsはW7以降、LinuxはGrub2とします。 > ここの部分はどういう意味かよく分かりません。 その時点のMBRで書き戻せばW7が起動できる環境ができます。 Linuxをrescueモードでオフライン起動し、セーブしてある各パーティションをddコマンドで戻します。 この段階でMBRのPartition Tableも新らしいTableとして設定されます。 ※質問にあるように「以前と(CHSが)完全に一致するパーティションの配置を復旧」という厳しい条件は満たしてていません。 しかし、元のCHSにこだわるよりもシステムが復旧できれば、それでいいのではないか、と思います。 もしもPartition Tableが更新されない場合でも、オフライン起動でのW7のシステム修復でW7は現在のデバイスのパーティションを設定してくれます。 次に、MBRにgrub2をLinuxのブートpartition(--root-directory=を指定して)インストールします。 この段階で、grub2ブート情報(grub.cfrg)が再編成されますので、Linux、W7のデュアルブート環境になります。 grub2ブートローダでの運用でOKならば、作業は終了です。 --- W7ブートマネージャで運用したい場合は、Grub4Dosを利用して次のようにします。 W7のシステムpartitionにGrub4dosの3つのファイル( grldr , grldr.mbr , menu.lst )を置きます。 W7 bcdeditコマンドでGrub4Dosのブートエントリを作成します。 Grub4Dos経由で Linux core.imgファイルを実行するようにmenu.lstに記述します。 以上でW7ブートメニューでLinuxを起動するW7、Linuxのデュアルブート環境になります。 --- 現時点でW7が起動できているのであれば、上記の作業と同じ要領で自分の環境に合わせて行なえばいいでしょう。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

こちらの方も以前からお世話になっていたようですね。 本当にありがとうございます。 > Versionが何も書いてありませんのでWindowsはW7以降、LinuxはGrub2とします。 Windows7、Grub2です。 書いておりませんでしたが、 一番最初に MBR を復旧しようとした時から、 HDD の Debian が起動できない状態では USB にインストールした Debian を使って作業をしております。 Windows のコマンドプロンプトは使ったことがありませんので、 もっぱら Linux ばかりです。 結局、「以前と(CHSが)完全に一致するパーティションの配置を復旧」するのはあきらめて Windows が入っている場所以外の HDD の空き領域でパーティションを適当に切り直して /dev/sda8 などの番号を以前と一致させて Debian 等のディストリビューションの中身を fsarchiver で書き戻しました。 そして、HDD の Debian は /media/Debian でマウントされているため sudo grub-install --root-directory=/media/Debian/boot /dev/sda から初めて、この直後の再起動がうまくいかなかったので grub-install のバリエーションを試して再起動ということを何回か繰り返しました。 途中で grub rescue っぽい画面も出たりしました(rescue とは書いてありませんでした)。 また、BIOS の boot 選択画面で HDD を選択した後に Grub2 の画面では Debian を選んだにも関わらず、 USB の Debian が起動してしまう、なんてことも途中ありました。 最後の辺りで、HDD から起動して Grub2 の画面を出そうとしても USB の Debian が挿さっていないと Grub2 の画面が出てくれない状態 (LiveDVD などの RescueMode において grub-install をすれば  こうはならないのかもしれませんね) において HDD の Debian を起動して sudo grub-install /dev/sda とした後に再起動すると、 USB の Debian が挿さっていない状態で起動できても Grub2 の画面で Debian のみが表示されて Windows・Mint が表示されない、という訳のわからないことが起きておりました。 何回か再起動の後に gParted で内蔵HDDを見てみると、 いくつかのパーティションのラベルに「CentOS」「Ubuntu」などの 削除してしまったはずの OS の名前が! ラベル名の情報がどこかに残っていて、 パーティションの場所がズレているので中身は全然関係なくなってますが、 古いラベル名だけが復活したようです。 この状態を何とかしようと思ったものでして、 この時点の MBR のバックアップも取らぬままに dd of=/dev/null of=/dev/sda bs=512 count=1 と軽率に打ってWindowsのパーティションさえも見えない状態にしてしまいました。 私って何ておバカさん、などと思いながら dd if=/media/linux-backup/MBR--2014-04-10.bu of=/dev/sda bs=512 count=1 を実行してから「Windowsの部分だけは復旧できたはず」と思いながら gParted を見てみました。 すると今度は、 一番最初にこの MBR を書き戻した時にそれのみが見えていた Windows(そのリカバリ領域も見えますが) だけでなく その後にパーティションを適当に切り直してfsarchiver で書き戻した Debian や Mint の存在までが見えているではありませんか! 今回起こったことから考えると、 パーティション構成やラベルなどの情報は 最新のものや古いものなどがどこかに残っていて 意図せずにそういったものが出てくることがあるようですので、 dd で MBR を書き戻すだけで MBR のバックアップを取った時点のパーティション構成が復元できるなどとは思わない方がいいのかもしれません。 sudo grub-install --root-directory=/media/Debian/boot /dev/sda から初めて、途中で1、2回再起動したり、 どの Debian( USB か HDD か) を実行している時に grub-install をどにように実行したかメモしておけばよかったのですが ここも詳しい経緯が既に記憶がハッキリしなくなっていて申し訳ないのですが、 最後に sudo grub-install /dev/sda の後に USB の Debian が挿さっていない状態で HDD の Debian のみを起動できるようになりました。 残りのパーティションに存在する OS群を Grub2 に認識させる手っとり早い方法は、 私の知る限りでは インストールに時間がかからないMint あたりを HDD の空き領域にインストールし、 その過程でインストーラから Grub2 を自動的にインストールしてもらうことです。 今回も grub-install による上手な解決法が分からなかったため、 結局この方法で 無事にHDD上の全ての OS が起動可能となりました。 とりあえず 皆さんのおかげでここまでたどり着きましたが、 付加的な情報を書き込んで下さる方がおられるかもしれませんので 1週間くらいは質問を閉じずにおこうと思います。 どうもありがとうございました。

  • 回答No.1
  • kteds
  • ベストアンサー率41% (1800/4290)

> clonezilla で HDD 全体のバックアップイメージを取りました。 このイメージでリストアすればいいと思いますが。 HDDのバックアップイメージがあるということはHDDクローンがリストアできるはずです。 > Linux のパーティションを全て削除し、・・・ この時点でのMBRを保存しておけばよかったと思います。 --- 「以前と(CHSが)完全に一致するパーティションの配置を復旧する方法」はわかりません。

共感・感謝の気持ちを伝えよう!

質問者からのお礼

ご回答ありがとうございます。 すみません、書き漏らしておりました。 clonezilla で HDD 全体のバックアップイメージを取ったというのは、 Windows のみを復旧したくなった時に使うためですので、 Linux のパーティションを全て gParted で削除した後です。 dd if=/dev/sda of=/media/linux-backup/MBR--2014-04-10.bu bs=512 count=1 を実行したのは、まだ Linux のパーティションが全て存在している時です。 なので、このファイルをMBRに書き込んでやれば Linux の各パーティションの存在が gParted で見えるはずだと思ったのですが。 > > Linux のパーティションを全て削除し、・・・ > > この時点でのMBRを保存しておけばよかったと思います。 ここの部分はどういう意味かよく分かりません。

関連するQ&A

  • partition情報をMBRに書き込んで復旧

    http://okwave.jp/qa/q8404421.html に書いてある操作で USB の MBR を消去しようとしていたのに $ dd if=/dev/zero of=/dev/sda bs=512 count=1 として、間違えてHDDのMBRを消去してしまいました! 今のところ、LinuxMintは サスペンドとそこからの復旧はできています。gdiskの結果は次のとおりです。 dizzy@PC03 ~ $ sudo gdisk -l /dev/sda [sudo] password for shin: GPT fdisk (gdisk) version 0.8.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1250263728 sectors, 596.2 GiB Logical sector size: 512 bytes Disk identifier (GUID): (略) Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1250263694 Partitions will be aligned on 2048-sector boundaries Total free space is 1250263661 sectors (596.2 GiB) Number Start (sector) End (sector) Size Code Name 再起動をしてしまったら、MBRが消失しているのですから grub rescue のメッセージさえ出ないと思われますので、サスペンドしか今のところできません。 Gpartedでディスクの修復をしようとすると、 「ディスク全体をスキャンする必要があります。 このスキャンには非常に長い時間がかかるかもしれません。」 と出ますので、できれば他の方法を使いたいし、知っておきたいです。 dizzy@PC03 ~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda10 20G 11G 7.8G 58% / udev 1.9G 4.0K 1.9G 1% /dev tmpfs 773M 1.1M 772M 1% /run none 5.0M 0 5.0M 0% /run/lock none 1.9G 312K 1.9G 1% /run/shm /dev/sda6 90G 12G 79G 13% /media/DATAFAT32_ /dev/sda9 20G 6.2G 13G 33% /media/Debian /dev/sda8 9.9G 6.8G 2.6G 73% /media/Ubuntu /dev/sda2 15G 7.3G 7.5G 50% /media/Recovery ファイルマネージャからも Recovery(Windows),Debian,Ubuntu,FAT32のデータ保存用パーティション が見えていて、中身のファイルを読み込むこともできています。 これらのパーティションのHDDの中での位置を Gparted,gdiskなどに分からせることができれば 残りの領域にどういうパーティションがあるかだけ検査させれば良いでしょうから、 HDD全体を最初からスキャンさせるより効率的になると思うのですが、 どうすればよいでしょうか? どうぞよろしくお願いいたします。 あと、grub-install の結果は次のとおりです。 dizzy@PC03 ~ $ sudo grub-install --recheck /dev/sda /usr/sbin/grub-probe: エラー: cannot find a GRUB drive for /dev/sda10. Check your device.map. Auto-detection of a filesystem of /dev/sda10 failed. Try with --recheck. If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org> dizzy@PC03 ~ $ sudo /usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub /usr/sbin/grub-probe: 情報: `/boot/grub/device.map' を開けません. /usr/sbin/grub-probe: 情報: Scanning for dmraid_nv RAID devices on disk hd0. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: Scanning for dmraid_nv RAID devices on disk hd1. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: scanning hd0 for LVM. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: no LVM signature found. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: scanning hd1 for LVM. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: no LVM signature found. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: Scanning for mdraid09 RAID devices on disk hd0. (字数制限のため中略) /usr/sbin/grub-probe: 情報: scanning hd0 for LVM. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: no LVM signature found. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: 情報: scanning hd1 for LVM. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: no LVM signature found. /usr/sbin/grub-probe: 情報: the size of hd1 is 3915776. /usr/sbin/grub-probe: 情報: /dev/sda10 starts from 283576320. /usr/sbin/grub-probe: 情報: opening the device hd0. /usr/sbin/grub-probe: 情報: the size of hd0 is 1250263728. /usr/sbin/grub-probe: エラー: cannot find a GRUB drive for /dev/sda10. Check your device.map.

  • Gpartedでのパーティション容量のリサイズ

    Gpartedでのパーティション容量のリサイズ こんにちは、よろしくお願いします。 前回、同じ題名で投稿したのですが、「添付した画像が見にくい」と指摘されたので もう一度新しく投稿しなおします。 現在、WindowsVistaとUbuntu(Linuxの一種)でのデュアルブートをしています。 現在パーティションの内容は、添付しましたJPEG画像のようになっています。 これは、UbuntuのLiveCDを起動して、パーティションエディタのGpartedを開いた画面です。 /dev/sda3が拡張パーティションになっており、その下にある /dev/sda5(タイプはext3)つまりUbuntuの容量を減らしてできた空きを、 /dev/sda2(タイプはntfs)つまりVistaに割り当てたいのですが、 実際に/dev/sda5を右クリックしてリサイズを行って空きを作り、 /dev/sda2を右クリックしてリサイズを行って容量を増やそうとしても、 最大容量を増やすことができませんでした。 どうすれば、Vistaのパーティション容量を増やすことができるのかをご存じの方がいらっしゃれば ぜひ方法を教えていただきたいと思います。 (Gpartedで指定した一連の処理は、一番最後に確定しなければ実際に行われないので、 パーティション状態は、添付した図の状態のままです。) ちなみに、sda2を拡張するのがどうしても無理な場合は、/dev/sda5をリサイズしてできた空きを、 新しくVistaのDドライブにしたいのですが、それが可能かどうか分からず、困っております。

  • パーテーション分割した場合の未割り当てについて

    現在、WinXPとubuntuをパーテーションを切ってデュアルブート(?)にしています。ubuntuのGPartedで見てみると以下の様になってます。 /dev/sda1 ntfs 51.76 GByte boot 未割り当て  未割り当て 3.49 Mbyte(メガバイト) /dev/sda2 ntfs 70.60 Mbyte(メガバイト) /dev/sda3 extended 24.86 Gbyte /dev/sda5 ext3 23.79 Gbyte /dev/sda6 linux-swap 1.07 Gbyte となってます。 この上から2、3個目の「未割り当て」とsda2(ntfs)はsda1に吸収できないのでしょうか? サイズが小さいので余りっぽいですが、こういうものですか? 直せるんでしょうか?

  • Gpartedでのパーティション容量のリサイズ

    Gpartedでのパーティション容量のリサイズ よろしくお願いします。 現在、WindowsVistaとUbuntu(Linuxの一種)でのデュアルブートをしています。 現在パーティションの内容は、添付しましたJPEG画像のようになっています。 これは、UbuntuのLiveCDを起動して、パーティションエディタのGpartedを開いた画面です。 /dev/sda5つまりUbuntuの容量を減らしてできた空きを、/dev/sda2つまりVistaに割り当てたいのですが、実際に、/dev/sda5を右クリックしてリサイズを行って空きを作り、/dev/sda2を右クリックしてリサイズを行って容量を増やそうとしても、最大容量を増やすことができませんでした。 どうすれば、Vistaのパーティション容量を増やすことができるのかをご存じの方がいらっしゃれば ぜひ方法を教えていただきたいと思います。 (Gpartedで指定した一連の処理は、一番最後に確定しなければ実際に行われないので、 パーティション状態は、添付した図の状態のままです。) ちなみに、/dev/sda5をリサイズしてできた空きに、NTFSフォーマットの新規パーティションを作成することができるのですが、これでは作成されたパーティションがVistaのものになるのかどうかがわからないので、行わないようにしました。 また、Vistaの「ディスクの管理」で、Ubuntuのパーティションを選択し、右クリックから容量を圧縮しようとしても、項目が現れず、できませんでした。

  • Gpartedでのパーティション容量のリサイズ

    Gpartedでのパーティション容量のリサイズ よろしくお願いします。 現在、WindowsVistaとUbuntu(Linuxの一種)でのデュアルブートをしています。 現在パーティションの内容は、添付しましたJPEG画像のようになっています。 これは、UbuntuのLiveCDを起動して、パーティションエディタのGpartedを開いた画面です。 /dev/sda5つまりUbuntuの容量を減らしてできた空きを、/dev/sda2つまりVistaに割り当てたいのですが、実際に、/dev/sda5を右クリックしてリサイズを行って空きを作り、/dev/sda2を右クリックしてリサイズを行って容量を増やそうとしても、最大容量を増やすことができませんでした。 どうすれば、Vistaのパーティション容量を増やすことができるのかをご存じの方がいらっしゃれば ぜひ方法を教えていただきたいと思います。 (Gpartedで指定した一連の処理は、一番最後に確定しなければ実際に行われないので、 パーティション状態は、添付した図の状態のままです。) ちなみに、/dev/sda5をリサイズしてできた空きに、NTFSフォーマットの新規パーティションを作成することができるのですが、これでは作成されたパーティションがVistaのものになるのかどうかがわからないので、行わないようにしました。 また、Vistaの「ディスクの管理」で、Ubuntuのパーティションを選択し、右クリックから容量を圧縮しようとしても、項目が現れず、できませんでした。

  • KNOPPIX MBRのバックアップについて

    (「日経Linux WindowsからLinuxに乗り換えよう」という本を見ながら手順に沿ってやっていたところで詰りました。) 1CD LinuxのKNOPPIXでMBRのバックアップを取りたいのですが…。 手順通り、まずフロッピーをフォーマットしました。 その次に、ターミナル画面を出して、MBRのバックアップをするコマンド $ dd if=/dev/hda of=/mnt/floppy/MBRbakbs=512 count=1 と入力すると出来るらしいんですが実際入力すると、 dd:opening ~/dev/hda': 許可がありません と表示され、バックアップされないようです。 (都合上、一部別の記号を代用しています。) この場合どうすればいいのでしょうか? どこに問題があるのでしょうか?

  • パーティション分割

    基本的な話だと思うのですが (Linuxあまり詳しくありません) HDD全体にUbuntuインストール済み環境にWindowsOSをインストール(デュアルブート環境構築) しようとしているのですがHDDのパーティション分割方法がよく分からずに悩んでいます LiveCDでUbuntuの再インストール処理を行いそこでHDD分割できることは確認したのですが もっと簡単にできないのでしょうか? パーティション管理ソフト(GParted)での操作も変更行えません    Linuxインストールしてあるパーティションに対しての操作不可?のように感じられます    添付画像の /dev/sda1 の領域を変更したいのですができません    未割当の部分に対しての変更操作はできます fdisk でできるのかなと思ったのですが コマンドがよくわかりませんでした

  • linuxでの第一パーティションの開始位置

    「sfdisk -d /dev/sda」で表示すると、第一パーティションの開始位置が63の場合と2048の場合があります。 どのような違いがあり第一パーティションの開始位置にヅレが生じるのでしょうか? 買ってきたHDDによるのでしょうか?それとも、CHS方式、LBA方式に関係しているのでしょうか?

  • パーティション空き領域の結合

    /dev/sda1 1GB ....(1)SWAP領域 /dev/sda2 3GB ...."/" /dev/sda3 3GB ...."/home" /dev/sda4 10GB ....(2)空き 上記構成にパーティションを切り、Linux(ディストリビューションはSUSE)をインストールしたのですが、 (1)のSWAP領域を削除し、(2)の空き領域といっしょのパーティションとして別OSを入れようとしたのですが、 (1)のSWAP領域を削除しただけでは、(2)の空き領域とは別パーティションとして認識されてしまいます。 /dev/sda1 1GB ....(1)空き←SWAP削除して。 /dev/sda2 3GB ...."/" /dev/sda3 3GB ...."/home" /dev/sda4 10GB ....(2)空き 下記のように(1)の空き領域を(2)の空き領域に移動させることはできますか? /dev/sda2 3GB ...."/" /dev/sda3 3GB ...."/home" /dev/sda4 11GB ....(2)空き+(1)空き SWAP領域作成せずにパーティション切りなおしてLINUX再インストールは できればしたくありません。 ご教授お願いします。

  • /dev/hda と /dev/hda1

    /dev/hda と /dev/hda1 はそれぞれどのような位置を指しているのでしょうか? 例えば、grub-install /dev/hda (つまり、MBR にインストール) とやった場合と grub-install /dev/hda1 (Linux パーティションの最初のセクタ) とやった場合では、GRUB がインストールされる位置が異なるようです。 プライマリ・マスタ・ディスクの先頭にあるパーティションの最初のセクタ=MBR だと思っていたのですが、 # dd if=/dev/hda of=mbr.dat count=1 bs=512 # dd if=/dev/hda1 of=top.dat count=1 bs=512 # diff -c mbr.dat top.dat とやると、2つのファイルは異なっているようですので、/dev/hda の最初の 1 ブロックと /dev/hda1 の最初の 1 ブロックは異なっているようです。 例えば、/dev/hda の 1 ブロックの直後に /dev/hda1 の 1 ブロックが来ているなどの構造について教えていただけないでしょうか。(URL 参照でも構いません) また、ブートローダを /dev/hda1 にインストールしてしまった場合、/dev/hda1 が空っぽでなかったとすると、/dev/hda1 の最初のセクタにあったデータが壊れてしまう等の問題が発生する可能性はあるのでしょうか? よろしくお願いいたします。