损坏的Backupt GPT表
之前已经问过这个问题，但提供的解决方案对我没有用。
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而不是Legacy中安装Wily，但计算机启动时很好，因为Legacy无法启动到操作系统。
sgdisk ：我是GPT fdisk（ gdisk ， sgdisk和cgdisk ）的作者，所以我非常了解GPT数据结构。
如果Windows在BIOS模式下启动，则它应该从MBR磁盘启动。 如果您只有一个磁盘，那么看起来Windows正在EFI模式下启动，因为您的一个磁盘使用GPT。 （但需要注意的是：如果你的分区表严重受损 – 比如gdisk由于某种原因无法识别的混合MBR – 它可能是一个真正的BIOS模式安装。）我提到这是因为你说你执行了EFI模式安装“因为[你]无法在传统模式下安装它”。 目前多重启动的规则＃1是以相同的模式安装两个操作系统。 换句话说，如果您的Windows安装处于EFI模式，则在BIOS / CSM / legacy模式下安装Ubuntu是您不应该做的事情。 这可能是一个侧面轨道，因为它听起来你做对了，但我想明确它，因为有很多不好的程序建议安装在BIOS / CSM /传统模式时不应该这样做。 我最特别想确保您不要尝试BIOS / CSM /传统模式安装来修复当前问题。 如果没有你真正得到BIOS模式Windows安装的信息，在BIOS模式下重新安装Ubuntu什么都不会做，只会在你现在拥有的问题上面造成新的问题。
现在，针对您的主要问题：我听说过这种事情发生了 – 也就是说， gdisk报告了一个损坏的备份分区表，用户修复了它，并且再次出现了损坏。 通常的原因是其他东西正在覆盖备份分区表。 有时这是RAID软件。 基于主板的软件RAID（通常称为“假RAID”）可以做到这一点，因为一些此类系统使用磁盘末端的空间（备份GPT数据所在的位置）来存储其数据。 如果您只有一个磁盘，则不需要RAID，因此您应该在固件和所有操作系统中禁用RAID设置。 在启动和不启动Windows的情况下重新启动可以帮助您弄清楚正在造成的损害，以及您需要调整的内容。 OTOH，如果您有多个磁盘并且它们正在RAID设置中使用，那么您需要在Ubuntu中激活RAID支持。 这涉及很多地方; 这里似乎是一个很好的起点，虽然我没有彻底阅读它。
由于磁盘加密或磁盘压缩软件等高级function工具，也可能出现此类问题。 这些工具有时会在磁盘的末尾转储内容，假设它未被使用。 （在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使用的全部内容。