Corrupt GPT on ZFS full-disks that shouldn't be using GPT

Quartz quartz at sneakertech.com
Sun Jun 28 06:52:41 UTC 2015


> 3. dmesg reports "the primary GPT table is corrupt or invalid" and
> "using the secondary  instead -- recovery strongly advised."

> Q: How can I remove the secondary GPT table from each of the drives
> that are participating in the zpool?

First off, you should double check what's going on with your layout. You 
didn't mention what system you're running or how this array was created. 
In several cases even if you meant to use the whole disk you can 
accidentally or unknowingly end up making gpt headers anyway, either for 
labels, compatibility, or because you did something that ended up 
requiring partitions. Also, a lot of zfs-based front ends (eg; freenas) 
always create zfs-on-partitions, so if this array was ported from 
another system it's possible it's supposed to have a legit gpt layout.

Additionally, some motherboards and expansion cards that offer raid 
services can cause problems that can screw with gpt. I have a 
motherboard where I have to set the sata ports as old style ide 
compatible, because turning on ahci mode automatically reserves/locks 
off a chunk of the end of the disk for raid metadata (even if I have the 
raid options disabled) causing dmesg to complain about corrupt gpt 
headers. So double check if you've changed anything related to that.

Either way, before you go any further, explain the steps you did to 
create this pool and dump out everything that the gpt commands tell you 
about the disks. It would especially help to get a dump of either/both 
headers to see what's going on there.


>I suppose I could offline and
> resilver each of them.

Simply resilvering is not guaranteed to fix the problem, depending on 
what's going on. If you're feeling adventurous you can always offline a 
drive and 'gpart destroy' it, then see what zfs says if you try to bring 
it back or reboot.


> I'm afraid to dd the secondary GPT header at
> the last 512 bytes of the drive.  Perhaps there is a way I can ask ZFS
> to do that for me?

Zfs doesn't mess with gpt directly like that, so no. If you don't want 
to 'gpart destroy' it for some reason it's not hard to nuke it yourself 
though with dd; you just need the output from 'diskinfo' and a calculator.




More information about the freebsd-questions mailing list