因此，不知何故，我的磁盘上的分区表变得疯狂：下次启动时系统无法启动，我在 BIOS 中反复被踢，并且没有可行的启动选项。 BIOS 仍然正确检测到磁盘，因此我启动了 LiveDVD 来看看发生了什么。
因此，在带有操作系统的磁盘中/dev/sdb，128GB SSD，没有分区表。 gpart 和 fdisk 都报告它为空。 fdisk 报告磁盘标签类型为 gpt。
我尝试运行 testdisk，它将分区表类型标识为 Intel（而不是 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
第二个问题与显示的值有关：开始列中有 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
第二个分区是引导分区，包含efi、grub2、vmlinuzs 等。第四个分区包含主文件夹，最后一个分区包含根目录。
由于我可以看到这些文件，因此我恢复了/etc/fstab/etc/lvm/，这确实表明系统是使用 LVM 配置的。
我不确定分区是否以某种方式扩展/逻辑，我什至不知道这对于 GPT 是否有意义，并且不限于 MBR。
第三个问题，鉴于 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
包含文件的分区是第 1 个 (EFI)、第 2 个 (/boot)、第 4 个 (/home)、第 7 个 (/)。我*在行尾用 标记了明显合法的分区。
编辑
我最终复制了驱动器dd，重新安装操作系统并通过安装旧分区来恢复数据这样。
答案1
在继续之前，请创建 ( dd) 磁盘映像，如果出现严重错误，您可以使用该映像来恢复它。
从你的帖子看来你已经阅读了测试盘指导。如果没有最好读一下。
问题1
Testdisk应该自动识别可用的分区类型，并且它找到分区的事实INTEL并不令人担心。您找到了分区，通过检查验证了内容，它们就是您要恢复的内容。不要忘记，这testdisk是使用相同的架构来查找它将写入修复的分区表的文件。所以一切看起来都不错。
问题2
如果你看一下指导您应该能够看到您感兴趣的数字是开始和结束列中的第一个数字。当这些是连续的时，分区之间没有间隙，并且它们很可能是连贯分区模式的一部分。这很好，而且，testdisk可以使用它从磁盘创建/推断的分区表来深入到文件级别这一事实再次激发了信心。
唯一让我担心的问题是起始地址和结束地址相同且不连续。也就是说，testdisk如果你要求它写入一个无效的表，应该会令人窒息。
问题 3 ....我应该...？
在此级别不会看到 LVM，但当修复的操作系统加载 LVM 模块并从复活的系统读取 LVM 布局时，会在启动时拾取 LVM。
GPT / MBR 只是不同格式的分区表。由于查找您的文件时使用的testdisk是它，因此您应该在恢复中使用它。
在您的位置上，我将根据您列出的模式继续并修复表，因为我知道我已经准备好了图像如果出现问题，我可以恢复到原始磁盘并重试。
如果有什么安慰的话，我有一个 1TB 驱动器去 ping 并经历了类似的痛苦决定该怎么做。最后，使用选择的默认模式一切顺利，testdisk但我手里有一个备份......以防万一。
如果有很多分区可供选择，那么我建议您发布完整的输出，然后您可能会得到一些更具体的帮助。
编辑
说实话，我对 5 个分区/MBR 难题有点困惑。
我能提供的最好的就是在您的情况下我会做的，即复制映像，尝试从每个映像中恢复一个以上分区作为 MBR（通过将映像安装在 testdisk 中，而不是 SSD 中），然后重建原始分区具有 GPT 架构的新媒体上的磁盘。如果有效，则将整个 shebang 迁移回您的 SSD。当您迁移回来以安装所有内容时，您需要重新安装grub并使用 GUID，fstab但这不是火箭科学。
最重要的是，您可以在图像副本上尝试任何您喜欢的操作，而不必担心。只需保留原始驱动器和一张图像的安全即可。