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

[Roderick Smith]

I'm the author of gdisk; psusi e-mailed me suggesting I look at this bug
report.

I believe the problem stems from an inconsistency in motherboard-based
RAID configuration or kernel drivers. Note that fdisk is reporting a
disk size of 312579695 sectors. This is an odd number, both in the
mathematical sense and in the sense that most (in fact, all, to the best
of my knowledge) hard disks today have an even number of sectors. The
only cases when I've seen modern disks with an odd number of sectors are
when those disks are being accessed via RAID drivers that set aside a
certain number of sectors for their own purposes. This works fine *IF*
everything using the disk accesses it the same way. If, however, some
tools access the "raw" version of the disk and others access it via the
modified view, then you get inconsistencies like those being reported
here. In most such cases, the solution is to disable the RAID features
by disabling the RAID options in the firmware and/or by uninstalling
RAID software or reconfiguring RAID settings under Linux.

The puzzling thing about this is that there seems to be an inconsistency
in the way gdisk and fdisk are viewing the disk, since the two programs
use the same system calls to determine the disk's size. (Or they did at
one time; it's conceivable their code has diverged over time.) This
could be explained if the two were fed different device identifiers to
access the disk. The bug report is vague on this detail. It's also
conceivable, if gdisk and fdisk have diverged in the way they identify
the disk size, that there's a bug in one or the other utility or that
there's a kernel or driver bug that's feeding inconsistent data via the
two kernel calls.

FWIW, gdisk does *NOT* use data in the protective MBR to determine the
total disk size, as the original bug report suggests; gdisk uses the
disk size as reported by the kernel using Linux system calls, just as
fdisk does.

Given that Mac OS X's Disk Utility and GParted under Ubuntu 10.04 both
work fine, I think it's very likely that this is an issue with an errant
RAID configuration or a kernel or driver bug in more recent versions of
Ubuntu. (All versions of GParted are very fussy about partition table
errors, typically showing a blank disk when they run into problems, so
if GParted under Ubuntu 10.04 worked, then that means it did not run
into a size inconsistency.)

-- 
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