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