Comment 11 for bug 945433

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