[Bug 945433] Re: Incorrect GPT length should be handled better

[Roderick Smith]

Psusi wrote: "This points to gdisk comparing the disk size to the MBR
size, rather than the GPT size."

I assure you that this is **NOT** the case! The code that computes the
disk size does **NOT** refer to MBR data structures. GPT fdisk works
fine on over-2TiB disks, for which MBR data structures are necessarily
much smaller than the disk's actual size. It also works fine with hybrid
MBRs, which have 0xEE partitions in the MBR that are generally much
smaller than the disk's size, and additional partitions that may or may
not pad out the length. You're seeing a correlation and inferring
causation -- always a risky endeavor!

Ahmad Moawya wrote: "I verified my disk using GPT fdisk (gdisk) and
verification was successful (found valid GPT and protective MBR)"

When I first read this statement, I assumed you meant that you used the
gdisk verify ("v" from any menu) function, but it occurs to me that you
might have meant that you launched gdisk and saw the "partition table
scan" results that said the GPT was valid. If so, please run gdisk again
and do a "v" on the disk. Also, check the gdisk output when you type "p"
to see what it reports as the disk's size in sectors. My suspicion is
that gdisk will report a disk size of 312579695 sectors and, when you do
a "v", it will report errors relating to the disk being too small for
the partitions it contains. If so, then it would appear that the HPA
feature is carving out part of the disk, as psusi suggests, and that all
your current tools are using this HPA-reduced size, but that the disk
was originally prepared with software (a Linux or other OS kernel) that
didn't respect the HPA, or with HPA settings set at some other value.
With the HPA now active, the fdisk output is largely irrelevant but
partially diagnostic, OS X's Disk Utility isn't reporting an error
because it's fairly lax about reporting errors in the placement of the
backup data, parted is throwing up its hands as it usually does with
damaged disks, and gdisk is reporting an error only when told to run a
diagnostic (or it would report an error if you told it to save the
partition table). That last is speculative, though; the gdisk data
you've provided is limited.

I have limited experience with HPA, but according to Wikipedia
(http://en.wikipedia.org/wiki/Host_protected_area), there are various
tools you can use to manipulate it. You should research this more, but
one possible fix would be to use one of those tools to disable HPA.
Another fix would be to use the "e" option on gdisk's experts' menu to
move the backup GPT data to where it belongs (given the HPA-reduced
size) and then re-save the partition table. It should then be possible
to use libparted-based tools on the disk.

Of course, even if I'm right about all this, that doesn't mean that
libparted shouldn't handle such errors better.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to parted in Ubuntu.
https://bugs.launchpad.net/bugs/945433

Title:
  Incorrect GPT length should be handled better

Status in “gdisk” package in Ubuntu:
  New
Status in “parted” package in Ubuntu:
  Triaged

Bug description:
  The GPT LastUsableLba claims the disk is longer than it actually is.
  Parted should handle this error more gracefully and allow for
  repairing it.  gdisk seems to let the error go undetected, possibly
  because it is using the size in the protective MBR rather than
  LastUsableLba.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/945433/+subscriptions