gptboot: invalid backup GPT header

[Warren Block]

On Sat, 1 Nov 2014, John wrote:

> Hello lists,
>
> Not sure if this is a hardware problem or a filesystem problem, so have
> cc'd to freebsd-fs@
>
> The "problem" is on newly-installed freebsd 10.1 RC3. I say "problem" in
> inverted commas because it's not stopping it from booting and the server
> seems to run allright, I'm wondering if it's anything to worry about. As
> well as seeing gptboot: invalid backup GPT header *before* beastie
> starts, I see the following in dmesg:
>
> GEOM: mfid1: corrupt or invalid GPT detected.
> GEOM: mfid1: GPT rejected -- may not be recoverable.
>
> There are 4 disks installed - mfid0,1,2 & 3. mfid0 is a regular ufs gpt
> based disk. mfid1,2 and 3 together form a zfs raidz array. A thread on
> https://forums.freenas.org/index.php?threads/gpt-table-is-corrupt-or-invalid-error-on-bootup.12171/
> describes a similar problem - the thing is though the "erroring" disk is
> not a GPT disk, and the one in the example was.
>
> # gpart list mfid1
> gpart: No such geom: mfid1.

My guess is that mfid1 was used as a GPT disk before it was used for 
ZFS.  Installing ZFS to the whole disk leaves an unused and apparently 
unwritten section at the end, so the backup GPT is still present in the 
last few blocks (usually 33 blocks, but not always).  That is the 
"invalid backup GPT header".

Clearing the last blocks will remove the warning, at least if the 
assumption is correct.  ZFS is not supposed to be using the last portion 
of the disk(*) to make replacing disks of slightly different sizes 
easier.  Still, I would back up either the whole array, the whole disk, 
or at least the last 33 blocks of mfid1 first.

*: I don't know exactly how much of the last part of the disk is not 
used by ZFS, do not recall an exact number being posted, and have not 
gone spelunking through the code for it.