损坏备份GPT表

Question

这个问题以前曾被问过，但所提供的解决方案对我没有用。

mao@CatLap:~$ sudo gdisk /dev/sda
[sudo] password for mao: 
GPT fdisk (gdisk) version 1.0.0

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): 

使用-v和-q，然后重新启动并不能解决问题。

虽然我不得不在UEFI中安装Wily，而不是Legacy，但由于Legacy不会启动到操作系统中，所以计算机可以很好地引导到操作系统中。

Answer 1

预先准备:我是GPT (gdisk、sgdisk和cgdisk)的作者，所以我非常了解GPT数据结构。

如果Windows是在BIOS模式下启动，那么它应该是从MBR磁盘启动。如果您只有一个磁盘，那么Windows在EFI模式下启动，因为您的一个磁盘使用GPT。(不过，请注意:如果您的分区表损坏严重-比如使用混合MBR，而gdisk由于某些原因没有识别-这可能是BIOS模式的安装。)我之所以提到这一点，是因为您说您执行了EFI模式的安装“因为你无法在Legacy模式下安装它”。现在多引导的第一条规则是在相同的模式下安装两个OSes。换句话说，如果您的Windows安装处于EFI模式，那么在BIOS/CSM/旧式模式下安装Ubuntu是您不应该做的事情。这可能有点偏颇，因为这听起来好像你做了正确的事情，但我想说清楚，因为有很多坏的过程，建议安装在BIOS/CSM/遗留模式时，不应该这样做。我特别希望确保您不会尝试BIOS/CSM/旧模式安装来解决当前的问题。如果没有BIOS模式Windows安装的信息，在BIOS模式下重新安装Ubuntu只会在现在的问题上造成新的问题。

现在，关于您的主要问题:我听说过这样的事情发生--也就是说，gdisk报告一个损坏的备份分区表，用户修复它，然后它再次出现损坏。通常的原因是其他原因是覆盖备份分区表。有时这是RAID软件。基于主板的软件RAID (通常称为“假RAID")可以做到这一点，因为一些这样的系统使用磁盘末端的空间(备份GPT数据)来存储其数据。如果您只有一个磁盘，您不需要RAID，所以您应该禁用您的RAID设置在您的固件和您的所有OSes。重新启动和不启动Windows可能会帮助您了解什么正在造成损害，因此您需要调整什么。OTOH，如果您有多个磁盘，并且在RAID设置中使用它们，那么您需要激活Ubuntu中的RAID支持。这包括了许多地方；这里似乎是一个很好的起点，尽管我还没有彻底阅读过它。

这些问题也可能发生，因为先进的功能工具，如磁盘加密或磁盘压缩软件.这样的工具有时会在磁盘的末尾抛出一些东西，假设它是未使用的。(在MBR下，最终分区后的空间经常会被浪费，所以这种方法通常是可行的。这是不安全的，但它经常起作用。如果您安装了这些工具，请删除它们，或者至少研究它们是否与GPT兼容，如果它们对GPT不友好，则更新或替换它们。

如果这些建议没有帮助，请尝试将磁盘的最后几个扇区提取到带有dd的文件中。首先需要在扇区中计算磁盘的大小(gdisk会告诉您这一点)，然后使用dd，如下所示：

sudo dd if=/dev/sda of=foo.img bs=512 skip=100021518

此命令将磁盘的内容(从100021518开始)复制到文件foo.img。您需要将skip=值设置为至少比磁盘上的扇区数少34个，因为GPT通常使用最后33个扇区。然后可以使用hexdump或类似的方法检查结果文件，如下所示：

hexdump -C foo.img | less

这里的想法是寻找字符串或其他线索，这些线索可能会告诉您是什么导致了问题。当然，在修复磁盘之前，您应该先看看磁盘的末尾。最后33个部门应该足够了，因为这就是gdisk所使用的全部。