gptboot: invalid backup GPT header

[John]

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.

# ls -la /dev/mfid*
crw-r----- 1 root operator 0x62 Nov 1 13:37 /dev/mfid0
crw-r----- 1 root operator 0x66 Nov 1 13:37 /dev/mfid0p1
crw-r----- 1 root operator 0x67 Nov 1 13:37 /dev/mfid0p2
crw-r----- 1 root operator 0x68 Nov 1 13:37 /dev/mfid0p3
crw-r----- 1 root operator 0x63 Nov 1 13:37 /dev/mfid1
crw-r----- 1 root operator 0x64 Nov 1 13:37 /dev/mfid2
crw-r----- 1 root operator 0x65 Nov 1 13:37 /dev/mfid3

# zpool status
pool: vms
state: ONLINE
scan: none requested

config:

NAME STATE READ WRITE CKSUM
vms ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
mfid1 ONLINE 0 0 0
mfid2 ONLINE 0 0 0
mfid3 ONLINE 0 0 0

errors: No known data errors

Should I worry?

[Warren Block]

Post by John
Hello lists,
Not sure if this is a hardware problem or a filesystem problem, so have
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
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.

[John]

Post by Warren Block
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.

Thanks for replying. So, in short - is my data on the array in any
danger, or is this just a cosmetic issue?

[I think the reason it happened is that during the install process,
where the installer asks you to choose partitions, I removed
*everything* from mfid1,2 & 3 as I knew zfs likes to deal with the raw
disk. I don't want to have to blat the system again though, unless
absolutely necessary].

[Warren Block]

Post by John

Post by Warren Block
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.

Thanks for replying. So, in short - is my data on the array in any
danger, or is this just a cosmetic issue?

If the guess is correct, it's just cosmetic. Unless someone panics at
the warning and tries to repair it.