だから何とか私のディスクのパーティションテーブルが奇妙になりました。次回システムを起動すると、システムが起動せず、BIOSから繰り返し追い出され、実行可能な起動オプションがありませんでした。 BIOSはまだディスクを正しく検出しているので、何が起こっているのかを確認するためにLiveDVDを起動しました。
したがって、オペレーティングシステムがあるディスク/dev/sdb、128 GB SSDにはパーティションテーブルはありません。 gpartとfdiskの両方が空であると報告します。 fdiskはディスクラベルの種類をgptとして報告します。
testdiskを実行してみましたが、パーティションテーブルタイプはEFI GPTの代わりにIntelとして識別されました。両方のタイプのパーティションを検索してみましたが、Intelだけが成功しました。
だから、最初の質問：インテルパーティションタイプはMBRですか？ディスクラベルがGPTですが、EFI GPTが機能しないのはなぜですか？
起動時に、ツールは次のパーティションのみを検索します。
Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
Partition Start End Size in sectors
1 P EFI GPT 0 0 2 15566 29 63 250069679
クイック検索（または完全検索）を実行すると、ツールはいくつかのパーティションを見つけます。そのうち5つは意味があります。
FAT32 0 32 33 33 69 36 532480 [SYSTEM]
Linux 33 69 37 163 207 44 2097152
Linux Swap 163 240 14 931 97 62 12328960
Linux 931 97 63 9038 187 45 130244608
Linux 9038 187 46 15565 209 4 104857600
2番目の質問示された値に関して、開始列に3つの値（例：0 32 33）と終了列に3つの値（例：33 69 36）がありますが、この値をどのように解釈しますか？
コマンドを使用してこのパーティション内を見ると、次のことがP: list fileわかります。
最初のパーティションには、次のEFIコンテンツが含まれています。
drwxr-xr-x 0 0 0 31-Jan-2019 19:26 EFI
drwxr-xr-x 0 0 0 13-Mar-2019 18:29 System
-rwxr-xr-x 0 0 0 21-May-2019 10:55 mach_kernel;5ce3af18
-rwxr-xr-x 0 0 34 13-Mar-2019 18:29 mach_kernel
drwxr-xr-x 0 0 0 26-Oct-2018 00:52 8310a92cdfe04b36b5a63736b6419b48
efi2番目のパーティションは、、、grub2svmlinuzなどを含むブートパーティションです。 4番目のパーティションにはホームフォルダが含まれ、最後のパーティションにはルートディレクトリが含まれています。
ファイルを見ることができたので、/etc/lvm/を復元しました。/etc/fstabこれは、実際にシステムがLVMで構成されていることを示しています。
パーティション化がどのように拡張/論理的であるかはわかりませんが、それがGPTに適しているのか、MBRに限定されないのかわかりません。
3番目の質問、testdiskが特定のパーティションを認識できることを考えると、この値を使用してパーティションテーブルを復元できますが、LVMはどうですか？ GPTはどうですか？これらのパーティションが正しく識別されているように見える場合は、以前の状況をどのように復元できますか？
ありがとうございます！
編集：拡張パーティションについて質問した理由は、明らかにすべてのプライマリパーティションを作成できず（これがMBRと考えられる）、拡張パーティションが必要ですが作成できないためです。
編集2：詳細検索で見つけたすべてのパーティションは次のとおりです。
Disk /dev/sdb - 128 GB / 119 GiB - CHS 15566 255 63
Partition Start End Size in sectors
>* FAT32 0 32 33 33 69 36 532480 [SYSTEM] *
P Linux 33 69 37 163 207 44 2097152 *
P Linux Swap 163 240 14 931 97 62 12328960 *
D Linux 931 97 63 9038 187 45 130244608 *
D Linux 4873 98 26 12980 188 8 130244608
D Linux 4875 43 33 12982 133 15 130244608
D Linux 9038 187 46 15565 209 4 104857600 *
D FAT12 9695 133 39 9695 198 39 4096
D HPFS - NTFS 15502 117 40 15566 19 5 1021952
ファイルを含むパーティションは、最初（EFI）、2番目（/boot）、4番目（/home）、7番目（/）です。私は行*の最後に明らかに正当なパーティションをマークしました。
編集する
最終的にドライブをコピーしdd、OSを再インストールし、古いパーティションをマウントしてデータを回復しました。だから。
答え1
続行する前にdd深刻な問題が発生した場合は、回復に使用できるディスクイメージを作成します（）。
あなたの投稿を読んだようです。テストディスクガイド。そうでない場合は、お読みください。
質問1
Testdisk使用可能なパーティションの種類は自動的に認識されなければならず、パーティションを見つけることを心配するINTEL必要はありません。パーティションが見つかり、スキャンで内容を確認し、回復するパーティションです。これはtestdisk、同じスキーマを使用して回復されたパーティションテーブルに書き込むファイルを見つけることを忘れないでください。だから、すべてがよさそうだ。
質問2
見たらガイド関心のある数字が開始列と終了列の最初の数字であることを確認できます。連続した場合、パーティション間にギャップがなく、一貫したパーティションパターンの一部になる可能性が高くなります。これは良いことであり、testdiskディスクから作成/推論されるパーティションテーブルを使用してファイルレベルにドリルダウンできるという事実は自信をもたらします。
私が心配する唯一のことは、開始アドレスと終了アドレスが同じで連続していないことです。つまり、testdisk無効なテーブルへの書き込みを要求した場合は、窒息する必要があります。
質問3....どうすればいいですか...？
LVMはこのレベルでは表示されませんが、リカバリされたオペレーティングシステムがLVMモジュールをロードしてリカバリされたシステムからLVMレイアウトを読み取ると、起動時に選択されます。
GPT/MBRはただ違います滞在パーティションテーブル。ファイルを検索するときに使用されるため、testdisk回復に使用する必要があります。
あなたの立場から私は準備ができていることを知っているので、あなたがリストしたパターンに基づいてテーブルを修正します。ビデオ問題が発生した場合は、元のディスクに復元して再試行できます。
慰めになると、pingを行う1TBドライブがあり、何をすべきかを判断するのに似た苦しみがありました。結局のところ、選択したデフォルトモードではすべてが順調に進みましたが、testdisk万が一の場合に備えてバックアップを準備しました。
選択できるパーティションが多い場合は、出力全体を公開することをお勧めします。その後、より具体的な助けを得ることができます。
編集する
正直なところ、私は5パーティション/ MBRの謎のために少し混乱しています。
私が提供できる最善の方法は、あなたの場合、イメージをコピーし、各イメージから複数のパーティションをMBRに復元しようとし（イメージをSSDではなくテストディスクにマウントする）ことです。 GPT アーキテクチャを使用して、新しいメディアにディスクの元のパーティションを再構築します。機能している場合は、Shebang 全体を SSD に再移行します。すべてをインストールするために再移行する場合は、grubGUIDを再インストールして使用する必要がありますfstabが、これはロケット科学ではありません。
何よりも心配せずに画像のコピーに欲しいものを試すことができます。元のドライブと画像を安全に保管してください。