Message from parted reads: Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partitiontable. Is this a GPT partition table? yes/no?
The scenario is the disk originally had linux installed, Fedora 16, which defaults to creating GPT disks. Then the user backed out of this and repartitioned the drive with a Windows 7 install disk, and installed Windows 7. By default (BIOS based hardware) it created a new MBR but does not wipe the primary or secondary GPT. Windows boots and functions fine. So the disk has a valid, not-corrupt GPT. And a valid, not corrupt, MBR. However, now any linux installer that depends on parted fails. It's not possible to either install linux in remaining free space on the disk, or shrink an NTFS volume - for dual boot. It's only possible to start from scratch. parted's behavior appears incorrect on three counts: 1. The message says the disk contains GPT signatures, but then goes on to say maybe the user deleted the GPT table. Well, which is it? In fact, the GPT is not corrupt, nor has it been deleted. So the error message is wrong, and thus misleading. 2. The question, "is this a GPT partition table" is linguistically clumsy and thus confusing. The user can't know this, certainly not based on the contradictions in the prior message. It might ask the user the question "Should parted treat /dev/sda as a GPT disk?" Yes/No. 3. In this particular example, the question probably shouldn't even be asked, because the UEFI spec pretty clearly says that a valid legacy MBR means it is not a GPT disk. The disk should be treated as an MBR disk. There is no 0xEE protective entry and all MBR entries are valid (don't overlap, don't define space outside of the disk, etc). But it gets worse: 4. Answering yes causes parted to see the old GPT partition. Answering no causes parted to see the disklabel as unknown. There is no apparent way to use the valid legacy MBR (without first destroying either the primary or backup GPT or both - something I don't believe parted can do). So there appears to be no way to handle this situation either correctly, or elegantly. Chris Murphy
