Comment 21 for bug 945433

@Roderick:
Sorry, I didn't give enough details. I did use the v option to verify and got the following:

No problems found. 526373 free sectors (257.0 MiB) available in 3
segments, the largest of which is 264223 (129.0 MiB) in size.

and with the p command, I got:

Disk /dev/disk0: 312579695 sectors, 149.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 777989DA-9962-2B05-18B6-4865BE87B817
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 8-sector boundaries
Total free space is 526373 sectors (257.0 MiB)

Number Start (sector) End (sector) Size Code Name
   1 40 409639 200.0 MiB EF00
   2 409640 42101263 19.9 GiB AF00 Apple_HFS_Untitled_2ae4
   3 42363408 312317551 128.7 GiB AF00

I think that after all this reading and testing, it's safe to assume that gdisk is off the hook, and by that I mean its bug-free :D

BTW, I'd like to use this chance to thank you for the amazing gdisk tool you made. It's probably the most advanced GPT disk utility available.

@Everyone, I think we can all agree that whether the kernel is handling the HPA correctly or not, parted must be patched to better handle this scenario.

For the mean time, I'll be flagging the gdisk bug as invalid (till an admin deletes it) since I now believe it's actually handling the disk correctly and the problem is basically that parted cannot handle the disk without the kernel disabling HPA (like older kernel did in 10.04).