GPTsync不匹配问题
我有一个混合磁盘。 在尝试将某些文件从另一个磁盘复制到此磁盘后，我丢失了我的OSX和Ubuntu启动function。 跑gptsync并得到：
Current GPT partition table: # Start LBA End LBA Type 1 34 1987 BIOS Boot Partition 2 1988 1029662719 Basic Data 3 1029662720 2108995583 Basic Data 4 2108995584 2109405183 EFI System (FAT) 5 2109405184 2517004287 Mac OS X HFS+ 6 2517266432 2667417599 Mac OS X HFS+ 7 2667417600 3900229631 Basic Data 8 3900230504 3907029118 Linux Swap Current MBR partition table: # A Start LBA End LBA Type 1 1 3907029167 ee EFI Protective Status: MBR table must be updated. Proposed new MBR partition table: # A Start LBA End LBA Type 1 1 33 ee EFI Protective 2 34 1987 da Non-FS data 3 1988 1029662719 83 Linux 4 * 1029662720 2108995583 07 NTFS/HPFS May I update the MBR as printed above? [y/N]
很明显，MBR表已损坏或不匹配。 但它根本没有反映正确的GPT表分区。 如何修复MBR以匹配GPT表（当然最多4个部分限制）？
问题很简单 – 我是否盲目地对gptsync的建议说“是”？ 它看起来很好但不完全如此…建议请解释上面的输出以使我的磁盘可用将非常感激。
谢谢！
从技术上讲，没有混合MBR是可以的; 混合MBR明显违反了GPT规范。 谁发明了他们应该为他/她自己感到羞耻。 不幸的是，它们是在Mac上双启动OS X和Windows的实际必需品。 （不过，这可能会随Windows 8而改变。）
也就是说，在混合MBR的通常非正式规则中，gptsync建议的那个是好的。 我怀疑你认为这不好，因为第一个分区（类型为“ee”）与你的任何GPT分区都不匹配。 这不仅很好，而且是必要的 ; type-0xEE分区是保护分区，需要将磁盘标识为GPT磁盘。 它并不是一个真正的分区定义，因为它没有指向可用于保存文件系统或其他东西的磁盘区域。 在符合标准的GPT磁盘上，此分区跨越整个磁盘（MBR本身除外）并且存在以防止GPT不知道的工具弄乱磁盘。 在混合MBR上，此分区的大小通常会显着缩小，并且最多可将三个“真实”GPT分区添加到MBR表中。
至于你是否应该接受这个分区表，我不确定; 这取决于Windows需要能够访问的分区。 如果Windows只需要访问/ dev / sda3（在GPT中; / dev / sda4在建议的混合MBR中），那么它应该按原样运行。 但是，如果Windows需要访问任何以后的分区，您可能需要获得更多创意。 您可以使用恢复和转换菜单上的h选项使用gdisk （Ubuntu中的gdisk软件包的一部分）执行此操作。 详细信息显示在gdisk基于Web的文档中。