损坏的备份 GPT 表

损坏的备份 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 无法启动进入操作系统。

答案1

首先:我是 GPT fdisk(gdisk、、sgdiskcgdisk)的作者,因此我非常了解 GPT 数据结构。

如果 Windows 以 BIOS 模式启动,那么它应该是从 MBR 磁盘启动的。如果你只有一个磁盘,那么 Windows 看起来就像是在 EFI 模式下启动的,因为你的一个磁盘使用的是 GPT。(但需要注意的是:如果你的分区表严重损坏——比如说混合 MBRgdisk由于某种原因无法识别——那么它可能真的是 BIOS 模式安装。)我提到这一点是因为你说你执行了 EFI 模式安装“因为 [你] 无法在传统模式下安装它”。如今多重启动的首要规则是以相同模式安装两个操作系统。换句话说,如果你的 Windows 安装处于 EFI 模式,那么你应该在 BIOS/CSM/legacy 模式下安装 Ubuntu不是正在做的事情。这可能有点离题,因为听起来你做的是对的,但我想澄清一下,因为有很多糟糕的程序建议在 BIOS/CSM/传统模式下安装,而实际上应该这样做不是完成。我尤其想确保您不要尝试 BIOS/CSM/旧模式安装来解决当前问题。如果您不知道您确实安装了 BIOS 模式的 Windows,则在 BIOS 模式下重新安装 Ubuntu 只会在您现有问题的基础上产生新问题。

现在,谈谈你的主要问题:我听说过发生过这种情况——即gdisk报告备份分区表已损坏,用户修复了它,但它又被损坏了。通常的原因是其他东西正在覆盖备份分区表。有时这是 RAID 软件。基于主板的软件 RAID(通常称为“假 RAID”)可以做到这一点,因为某些此类系统使用磁盘末尾的空间(备份 GPT 数据所在的位置)来存储其数据。如果你只有一个磁盘,则不需要 RAID,因此你应该在固件和全部您的操作系统。重新启动并启动 Windows 和不启动 Windows 可能会帮助您找出造成损坏的原因,从而确定需要调整的内容。另一方面,如果您有多个磁盘并且它们正在 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用途。

相关内容