0.イントロ。
状況は次のとおりです。 160GBのネジがあります。 40GBと120GBの2つのセクションがあります。 2番目のシステムとしてubuntaをインストールするために、120 GBの内訳が作成されました-> 100 + 10 + 2 + 8。
さらに、変更をロールバックするために、ディスク（10、2、および8）が1つの20 GBにマージされ、NTFSでフォーマットされました。 これに対応して、MBRで手術が行われ、その結果は彼女の死でした。
まとめ
1.システムの起動時に、MBRヘルパーが見つかりませんというメッセージが表示されます。
2. fdiskは、1つの大きな160GBドライブを示しています。
愚か者は、これが楽しい夜の始まりであることを理解しています。
さらに、カットの下で、問題の解決策。
1.パーティションテーブルの回復
1.1。 別れの魔法
サイズが100MBのこのLiveCD \ USB ディストリビューションには 、ディスクを操作するための膨大なソフトウェアが含まれています。 故障から回復まで。
それらのうち、 gpart 、 testdisk 、 fdisk 、およびms-sysが必要です 。
1.2。 Gpart
gpartは、メディアには存在するがテーブルにはないパーティションについて、セクタごとにディスクをスキャンするユーティリティです。 彼女の作品では、既存のテーブル（存在する場合）を無視します。 このプログラムは、ドイツのプログラマーMichail Brzitwaによって開発され、現在ではサポートされていません。 遅い開発は、FedoraおよびDebianチームが主導しています。 現在のバージョンは0.1hです。
このユーティリティを使用すると、パーティションテーブルを最も迅速かつ簡単に復元できますが、いくつかの欠点があります。 第一に、開発はずっと前に放棄され、第二に、セクションを正確に決定できない場合があります。
gpartは2つのモードで動作します。 これは、迅速な分析と詳細なスキャンです。 場合によっては、最初のモードで十分です。 2番目を見てみましょう。
gpart -if /dev/sda
-i-対話モード。 見つかったパーティションごとに、保存するかスキップするかという質問が表示されます。
-f-フルディスクスキャン。
かなり長い時間が経過すると、可能なセクションを含むレポートが作成されます。 また、録音する前に注意深く確認する必要があります。
サンプルレポート（私のものではない）：
Begin scan...
Possible partition(DOS FAT), size(1907mb), offset(0mb)
Possible partition(SGI XFS filesystem), size(5730mb), offset(1907mb)
End scan.
Checking partitions...
Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary
Partition(Linux ext2 filesystem): primary
Ok.
Guessed primary partition table:
Primary partition(1)
type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA)
size: 1907mb #s(3906544) s(16-3906559)
chs: (0/1/1)-(1023/19/16)d (0/1/1)-(12207/19/16)r
Primary partition(2)
type: 131(0x83)(Linux ext2 filesystem)
size: 5730mb #s(11736000) s(3906560-15642559)
chs: (1023/19/16)-(1023/19/16)d (12208/0/1)-(48882/19/16)r
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
すべてが問題なければ、パーティションテーブルに書き込むことに同意し、指を交差させて再起動します。
私の場合、プログラムは故障前のパーティション（40および120）を特定しましたが、これは適合せず、別の復旧方法を探しました。
1.3。 テストディスク
注：このユーティリティの詳細については、 この投稿で説明します。ここでは繰り返しません。
このユーティリティは前のものと似ていますが、いくつかの利点があります。
1.最新かつ積極的にサポートされています。
2.主観的に、はるかに高速に動作します。
3.より機能的。
4. ncursesに基づいたシンプルなコンソールインターフェイスがあります。
行こう！
1.最初のウィンドウで、[新しいログファイルの作成]を選択します。
2.目的のディスクを選択します（/ dev / sda）-> Proceed;
3.パーティションのタイプをIntelとしてマークします。
4. [現在のパーティション構造の分析]を選択し、失われたパーティションを検索します。
5.見つかったパーティションが正しい場合、[バックアップ]をクリックして手順6に進みます。どこかにエラーがある場合は、ディスクをすばやくスキャンできます（クイック検索）。
6.セクションのある緑色のリストがすでにここに表示されています。 OKなら記録し、そうでなければディープサーチを実行します。
私の場合、結果はgpartの結果に似ていましたが、これは正しくありません。
ディープサーチを開始し、約40分待ってから、私は私の魂がとても病弱になっていたという答えを受け取りました。
いくつかのパーティションが見つかりました。それらは上下に重ねられていました（これらは元の（操作前の）120GBと新しいパーティション、100GBでした）。 リモートとして不要であることに注意して、ディスクにテーブルを書き込んで再起動しました。 幸いなことに、すべてがうまくいき、コンピューターが元の状態に戻ったので、私は明確な良心をもって寝ることができました。
3. MBRリカバリ
このタスクには、ms-sysがあります。
まず、MBRの内容を確認します。
ms-sys /dev/sda
/dev/sda has an x86 boot sector
it is unknown boot sector
これで、このディスクにブートセクターがないことがわかります。
このユーティリティは、さまざまなオペレーティングシステムのMBRで動作します。 リストは、引数なしでプログラムを実行することで取得できます。 私の場合、Windows 7から必要でした。
MBRをディスクに書き込みます。
ms-sys -7 /dev/sda
Windows 7 master boot record successfully written to /dev/sda
私たちはチェックします：
ms-sys /dev/sda
it is Microsof 7 master boot record, like the one this
program creates with the switch -7 on a hard disk device.
以上で、必要なMBRがインストールされ、再起動できます。
3.アウトロ
この投稿は、自分で問題を最初から作成し、真夜中に必要なことをしない方法の例です。 しかし、これは非常に貴重な経験となり、ここで説明しようとしました。
たぶん誰かが役に立つでしょう。 実際、このような状況に陥ることはそれほど難しくなく、詳細なマニュアルもありません。