Warning about large hard discs, GPT, and Gigabyte Motherboards such as GA-P35-DS4

Or, Gigabyte BIOS considered harmful

After changing the motherboard, a computer became unbootable because the Gigabyte BIOS created a Host Protected Area (HPA) using sectors already allocated to a disc partition, corrupting the partition table and overwriting data.

What Gigabyte are trying to do is store a copy of the BIOS onto disc in order to secure the computer against viruses. The process is explained over here in the section titled "GIGABYTE Xpress BIOS Rescue™ Technology" (and is referred to in the specification of the motherboard as "Virtual Dual BIOS"). At boot time, a copy of the BIOS is stored into an unused section of the disc by creating a Host Protected Area. If a virus corrupts the BIOS then it can apparently detect this and restore the safe copy of the BIOS from the disc. Magical!

This process goes badly wrong when you have discs larger than 2TB. The traditional partition table format, which dates back to the early 80s, runs into a limit when discs reach 2TB. A new partition table format was created called GUID Partition Table (GPT) which handles much larger discs.

If you have certain Gigabyte motherboards with the Virtual Dual BIOS feature, then as the computer boots it will try and create an HPA on the first hard disc, and save the current BIOS there. One assumes that if the partition table indicates that the disc is already full, then the BIOS will avoid creating this HPA. What seems to be happening with large hard discs with GPT, is that the BIOS doesn't understand the partition table, doesn't realise that the all space on the disc is entirely accounted for already, then grabs some of the space from the end of the disc and overwrites it with a copy of the BIOS.

Once the HPA has been created, the size of the disc that is reported to the OS changes. This means that the values stored in the GPT structures don't match those reported by the disc so may make it impossible to boot from the disc - which is what happened to me.

How do I tell if I have this problem?

You are likely to see this problem if you have a disc larger than 2TB that you partitioned with a GPT on a different motherboard then attached to the Gigabyte motherboard as the first hard disc.

For me, I had a 1.5 TB disc with a /boot partition and 2 3TB discs in raid-1 via Linux software raid (mdadm). I had partitioned these discs on a different motherboard and the computer would boot without problems, however when I switched to the Gigabyte motherboard it would no longer boot. Specifically, I would receive a grub error like this:

error: disk 'mduuid/3c620ba3b6ebc2ba2dec4bdc61f7191b' not found.
Entering rescue mode...
grub rescue>

When I booted from a usb stick and attempted to mount the raid partition it was only able to load one of the discs:

ubuntu@ubuntu:~$ sudo mdadm --assemble /dev/md0
mdadm: /dev/md0 has been started with 1 drive (out of 2).

I then ran gdisk to inspect each of the two discs forming the raid array, gdisk printed various errors about the disc that the BIOS had interfered with:

ubuntu@ubuntu:~$ sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.8

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

Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.

Command (? for help):

If one performs the recommended verification step, 5 errors are detected:

Command (? for help): v

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 5860531055 sectors, needs to be 5860533168 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 5860533134, but backup header is at
5860533167 and disk size is 5860531055 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!

Command (? for help):

In fact there is only 1 error, which is that part of the disc has been co-opted by the BIOS. This can be seen with hdparm (contrast sdb which has been corrupted with sdd which is in its original state):

ubuntu@ubuntu:~$ sudo hdparm -N /dev/sdb

 max sectors   = 5860531055/5860533168, HPA is enabled
ubuntu@ubuntu:~$ sudo hdparm -N /dev/sdd

 max sectors   = 5860533168/5860533168, HPA is disabled


How do I fix the problem?

You must either live with the HPA, or remove it and ensure you never again boot with a the GPT disc as primary. Even if you decide to live with the HPA you will need to temporarily remove it so that you can backup your data or resize the partition and filesystem.

So regardless of what you choose to deal with this problem, you will need to disable the HPA and make the entire disc available. This can be done with hdparm, by setting the visible sectors to the full amount with the parameter "-N p<full amount of sectors>" as below:

ubuntu@ubuntu:~$ sudo hdparm -N /dev/sdb

 max sectors   = 5860531055/5860533168, HPA is enabled
ubuntu@ubuntu:~$ sudo hdparm -N p5860533168 /dev/sdb

 setting max visible sectors to 5860533168 (permanent)
 max sectors   = 5860533168/5860533168, HPA is disabled

Now that this has been done, the GPT partition table will correspond to the number of sectors reported by the disc (although some data has been unavoidably lost when the BIOS overwrote the end of the disc). However if you reboot and this disc is still the primary disc then the BIOS will just create the HPA again!

By ff

Systems software engineer with interests in C/C++/Rust on Linux, electronic music and games.

9 replies on “Warning about large hard discs, GPT, and Gigabyte Motherboards such as GA-P35-DS4”

Thanks for the great article. You describe exactly the problem I had, too. Fortunate enough, my computer - used as a server - still boots from a RAID1 in degraded mode (only sdb). This is when I found out about this rather stupid approach from Gigabyte motherboard to destroy data on my hard disk. It's sad that there seems to be no better approach, e.g. disable HPA usage by the motherboard completely or so. I will probably need to move data, resize the partitions and such to reserve the space for the HPA 🙁

In the end I solved it by keeping 3 old hard discs in the machine that are less than 2GB in size, and making sure they are the first that the mobo sees. Hopefully this should keep the machine on the road for the lifetime of the motherboard! One of the discs failed last week as it happens so I'm down to two.

If you were flexible with your partitioning maybe you could create two partitions - with one ending at the HPA and the second starting just after it. This wasn't suitable for me to try though as I want one big volume containing the entire disc (well entire raid-1 pair of discs).

Right, I also thought about your solution, like a 64MB USB thumb drive to end up as "primary" for the MB to detect and write its stuff there 😉
Actually, I looked and found more solutions. First, some forum entries mentioned that AHCI and RAID mode (instead of "legacy" IDE) prevent the bios save "feature" to kick in, i.e. leaving the disks untouched. Also, I found a BIOS update on . I had F2 in before, now F4 which actually adds an option "Save BIOS to disk drive" which is "Disabled" by default so it looks like Gigabyte learned from their mistake and made the situation better.
Doing this together with re-setting the device configuration as you proposed with hdparm and re-adding the drives to the RAID should fix it for good 🙂

If there is a simple BIOS fix that would be great, because requiring specific types of disc to be installed to particular SATA controllers isn't very robust...

I'm pretty sure I have my BIOS configured to AHCI mode already but its worth another look.

I did update the BIOS on my motherboard when this happened but it didn't make any difference and I didn't notice any new options such as "Save BIOS to disk drive". I will have another look at my BIOS options, as if there is an option to simply switch it off that would be fantastic!
In which section do you find "Save BIOS to disk drive"?

I have 3 different Gigabyte boards.
1) GA-P35-DS3L ReV2
2)GA-M61P-S3 ReV1
3)GA-M474GM-S2 ReV 4.1

All boards had Award Bios 6

1) Had no bios option to disable HPA, updated bios to 9 and now I see option in Advance Backup Bios Image to HDD it is disabled by default.
2) Had no bios option to disable, updated bios to 7 (only bios update available) but still no option to disable in bios.
3) This board had bios 6 with option for Backup BIOS Image to HDD disabled by default. So no bios update required.
Boards 1 and 2 temporarily resized countless 1TB drives that were brought back to full size (with no data loss) by HDD Capacity Restore tool.
One drive was struggling due to power outage and on the 2nd HPA error after using HDD Capacity Restore tool it now shows as unallocated so I am still trying to get data back on that drive.

Its interesting that you found an option to control this feature on the GA-P35-DS3L ReV2 which is surely quite similar to my GA-P35-DS4. Thanks for the update.

Thank you for posting this. I got stung by this a week ago and have been searching for a solution for days. This is stated perfectly clearly and understandably. You have saved me a great deal of work.

Leave a Reply

Your email address will not be published. Required fields are marked *