Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having troubles getting my partitions to show up correctly on one of my drives.


  • Linux 3.10.10-1-ARCH
  • Disk is 2TB and has GPT with two partitions.
  • The two partitions hold approx 700GB each so there is defiantly enough room for everything.
  • The data on the disks have full backups but would take me a long time to rebuild (offsite backup) so if possible id really like to fix this.
  • I created the partitions in gparted on a livecd then dd'd data on from old disks.
  • Both partitions are ext4 but that shouldn't matter much.

The problem I run:

sudo gdisk /dev/sdb

And I get:

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

So then I did v to reveal the exact issues:

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 1953569134 sectors, needs to be 3907029168 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 3907029134, but backup header is at
3907029167 and disk size is 1953569134 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 2 is too big for the disk.

Identified 5 problems!

After running e then v again I get:

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: partition 2 is too big for the disk.

Warning! Secondary partition table overlaps the last partition by
1953459891 blocks!
You will need to delete this partition or resize it in another utility.

Identified 3 problems!

I can now see the correct partitions using p:

Disk /dev/sdb: 1953569134 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D690A9B2-EA00-4D2E-9E18-0D4545A8683A
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953569100
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      1953515519   931.5 GiB   0700  
   2      1953515520      3907028991   931.5 GiB   0700 

I am stuck at this point and any help would be greatly appreciated.

share|improve this question
What happens when you try to mount the partitions? – Flup Sep 13 '13 at 14:44
the partitions are not there. I cant write that partition table to the disk and hence the kernel sees it as having no partitions. – Nick Sep 13 '13 at 15:23
up vote 2 down vote accepted

First, you claim:

  • Disk is 2TB and has GPT with two partitions.

Unfortunately, gdisk disagrees with you:

Disk /dev/sdb: 1953569134 sectors, 931.5 GiB

I recommend you double-check the disk's claimed size; it's usually printed on a sticker on the disk's body. If you've really got a 931.5GiB (1TiB) disk, then there's no way you can fit two ~700GB (gdisk claims 931.5GiB) partitions on it. So if gdisk has the right data, you'll have to either get a bigger disk or (if you're using no more than 1TB of actual space within the filesystems on the original) do a file-level backup of the original to the 1TB target disk.

If your disk is marked as being a 2TB model, then either it's mis-marked or you're running into problems with the Host Protected Area (HPA) feature. This feature enables you to "hide" a certain amount of disk space for various obscure purposes. Judging by online posts I've seen, though, it's sometimes mis-set and causes problems like yours. You can view and change this feature with the -N option to hdparm. Typing sudo hdparm -N /dev/sdb should show you the current HPA settings for your drive. If this feature is active, type man hdparm and read the section on the -N option. Basically, you'll need to pass the true number of sectors on the disk via -N to reset it and use its full capacity.

share|improve this answer
Thank you, It was the Host protected Area, I would love to know how the hell that happened – Nick Sep 23 '13 at 6:05
I have the same issue: SG_IO: bad/missing sense data, sb[]:..max sectors = 0/1, HPA is enabled. Crazy. Is it safe to change this when I have the drive full of important stuff? I don't have another drive handy to dump everything onto... – macmadness86 Mar 1 '15 at 17:46
I would never describe mucking with low-level disk tools "safe." If you lack adequate backups, then you're playing with fire, even with disks that seem to be functional, and my recommendation is that you acquire sufficient backup capacity. This goes double before doing anything tricky with partitioning tools or utilities that adjust features like the HPA. – Rod Smith Mar 5 '15 at 19:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.