HPA Caused Data Corruption - Saga
 

Having installed a new 3 terrabyte WD disk I was happy that I now "had room". Imagine my horror when switching on my PC to find the new disk partition table was completely corrupt.
This turned out to be cause by a bug in ALL old (8-10 years) BIOS of Gigabyte motherboards - unable to handle Hidden Protected Areas (HPA), the system ended up corrupting the partition table.
Maybe I should blame Gigabyte for the problem, but I rather blame Western Digital, who did not warn in the disk instructions of this HPA caused issue about a major manufacturer of boards.

To solve the partition table (GPT) problem, I reset the HPA - This can be done with an MSDOS utility HDAT2 or with the Linux command 'hdparm -N p<native disk size> <device>'
hdparm utility did not work and so I used HDAT2 with the old Gigabyte board. Then, I reset the partitions as they were prior to the corruption and then used 'fsck' and the disk was successfully recovered.
Phew ...

As already mentioned, when I powered on the PC to the problem repeated. Every powerup, the HPA would lead to corruption!
At this stage I purchased a new motherboard and another disk (4TB) to make a backup of the 3TB disk.
With the new motherboard (ASROCK), the HDAT2 utility did not work and neither did hdparm. hdparm reported crazy native sizes such as 45.4 PB.

4TB Disk (the backup)

I then procured an alternative computer - an HP Probook 6560b Notebook and connected the disks vie eSATA. This time hdparm dis work. For the 4TB the result was:
So, at this stage I am seeking careful advice about how to continue the recovery, because some messages from 'parted' I am unsure about. The intention for the 4TB (WD40EZRX) disk is to :
and then use fsck. Partition 1=copy of original disk partition 1. Partition 3=copy of original disk partition 2.

Unfortunately parted throws some messages I am unsure about.
Testdisk Utility on the 4TB (backup):
The utility it reports a GPT partition table and analyze shows the first partition Start=2048. This is the HPA corrupted situation.
However if I then continue with a 'Quick Analyze' it shows three partitions as expected, all highlighted in Green, with the correct partition name. It also reports 'Structure: OK'
First Partition:
But if I do 'List Files' on the first partition, it does not look good - only 2 files are appear OK. The rest of the listing is in red with filename similar to recup_dir. I reckon I must have ran a fsck on this partition without fixing the HPA issue.
Second and Third Partitions: the listings look good. Nothing in red.

3TB Disk WD30EZRX (the original)
hdparm -n /dev/sdc reports
maxsectors 5860533168/5860533168, HPA is disabled

The 'testdisk' utility it reports a GPT partition table and analyze shows the first partition Start=2048. This is the HPA corrupted situation.
However if I then continue with a 'Quick Analyze' it shows two partitions as expected, all highlighted in Green, with the correct partition name. It also reports 'Structure: OK'
List Files' on both partitions shows that files appear OK.

The testdisk and backup situation would suggest a happy ending, but I am unsure about the parted messages. If I can restore the GPT to 1 TB and 2 TB partitions without an HPA, then I am confident fsck can do the rest.

Thanks for any advice in advance.

OK, this might be a really good time to chill out for a while.
Whilst you may have had some problems, it looks like you're over-reaching now. With the "problem" m/board(s) out of the way, you should be o.k. - if a disk has a HPA on it (and some are shipped that way), it isn't likely to change.

Nope.
This is you mis-interpreting the data. All the tools now align partitions this way to accomodate newer disks having 4k sectors - this is now the *default* partition alignment.
HPA is allocated before the operating system even gets to look at the disk. This is the tools using what they can see. Personally I like parted for playing with gpt disks - it's not as obvious to use as some of the old tools, but let it do its thing. Also use its alignment check - that confirms the 4k alignment in case something else (like a GUI installer) mis-aligns partitions the old way.

I think everything should be fine from now on.
Interestingly, I have used Gigabyte boards for years, and haven't run into this.

Thanks for the reply syg00
http://lime-technology.com/forum/index.php?topic=4638.0


If I read you correctly you are suggesting the first partitioning with the old Gigabyte board also started the first partition at 2048. Due to the behaviour describe in the link above, can we be sure the first partition began at 2048 during the first partition event on Arch Linux with gparted?
All I know is removing the HPA, recreating the partitions starting at 0.0TB and then using fsck worked.
I just can't remember how I handled the parted questions about moving (M) the backup GPT and start sector (SS) for the first partition.
I suppose I have 6 options

M yes SS 2048 (your suggestion)
M no SS 2048
M yes SS 34 (lowest possible)
M no SS 34

I will try your suggestion after backing up.
I've been chilling on this for months. WD were unhelpful. But now I need the space and the data back.