FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though)

[Adam Strohl]

I've been deploying FreeBSD 9 without issue on a number of
near-identical servers for a client, but have run into an interesting
annoyance when I hit the two DB servers.

These DB servers have an LSI 3ware 9750-8i (running a 6 disk RAID 10 in
a single 3TB virtual volume) which puts them apart from the other two
servers in this cluster (which don't show either issue I am about to
discuss). Otherwise the hardware is identical (Dual Xeon E5620s, 16GB
RAM). I've also never seen this before on other physical (or VM)
FreeBSD 9 instances and I've probably done 50+ FreeBSD 9 VM and physical
installs at this point (and run through the installer process probably
over 150 times :P).

Before I get into the GPT error, I want to mention this in case its
relevant:

I found I had to partition via the shell (gpart create/gpart add/etc
etc) the disks during install or the kernel would fail to re-mount the
root disk after booting into the new OS. If I used the default layout,
or the partition GUI at all (ie; 'manual mode') the new OS wouldn't
remount root on boot.

I could manually specify the proper root device ie; ufs:/dev/da0p3 and
continue booting without issue, so this is an installer thing. I'm
sure I could have fixed this in /boot/loader.conf or similar but wanted
to try to figure out what was breaking (now I know its something the
installer is doing since it doesn't happen when I do it manually). So I
kept reOSing it doing different things and ultimately found shell-based
manual partitioning worked fine.

However, I see the following error right before BTX comes up (and did
previously when using the installer's partition GUI):

gptboot: invalid backup GPT header

The machine boots fine, so I'm not stuck .... but it is an annoyance for
an A-type sysadmin like myself. Even if its superficial I dislike
setting up a client's machine to generate "errors" on boot, especially
without an explanation or understanding behind it. I also obviously
wanted to raise the issue here in case there is actually a rare problem
or this is a symptom of one.

I could find nothing that related specifically to this issue, so I was
wondering if anyone else had seen this or had thoughts.

My suspicion is that maybe the large size of the volume (3TB or 2.7TB
formatted) makes it too large for the boot loader to "address all of"
and thus can't get to the end of the disk where the backup GPT header is
to validate it......

Or maybe the RAID adapter is doing something weird at the end of the
disk. This seems unlikely since it presents the RAID as a single volume
so I'd assume it would hide any tagging or RAID meta data from the OS'
virtual volume though.

That's about all I can think of.

Selected dmesg output:
LSI 3ware device driver for SAS/SATA storage controllers, version:
10.80.00.003
tws0: <LSI 3ware SAS/SATA Storage Controller> port 0x1000-0x10ff mem
0xb1940000-0xb1943fff,0xb1900000-0xb193ffff irq 32 at device 0.0 on pci4
tws0: Using legacy INTx
tws0: Controller details: Model 9750-8i, 8 Phys, Firmware FH9X
5.12.00.007, BIOS BE9X 5.11.00.006

da0 at tws0 bus 0 scbus0 target 0 lun 0
da0: <LSI 9750-8i DISK 5.12> Fixed Direct Access SCSI-5 device
da0: 6000.000MB/s transfers
da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C)


Let me know anyone wants to see anything else/has seen this/has any
theories!

--

Adam Strohl
A-Team Systems
http://ateamsystems.com/

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Adam Strohl]

Thanks Andrey,

I've just recompiled /boot/gptboot after updating gpt.c and installed it
via:

gpart bootcode -p /boot/gptboot -i 1 da0

I still see "gptboot: invalid backup GPT header" on boot (but it does
still boot).

On 5/2/2012 12:58, Andrey V. Elsukov wrote:

> On 30.04.2012 23:14, Adam Strohl wrote:
>> da0 at tws0 bus 0 scbus0 target 0 lun 0
>> da0:<LSI 9750-8i DISK 5.12> Fixed Direct Access SCSI-5 device
>> da0: 6000.000MB/s transfers
>> da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C)
>>
>>
>> Let me know anyone wants to see anything else/has seen this/has any theories!
>

> Can you try patch from the r234693, update and reinstall gptboot, does it help?
> http://svnweb.freebsd.org/base?view=revision&revision=234693

[Mark Saad]

On Wed, May 2, 2012 at 5:03 AM, Adam Strohl
<adams-...@ateamsystems.com> wrote:
> Thanks Andrey,
>
> I've just recompiled /boot/gptboot after updating gpt.c and installed it
> via:
>
> gpart bootcode -p /boot/gptboot -i 1 da0
>
> I still see "gptboot: invalid backup GPT header" on boot (but it does still
> boot).
>
>
> On 5/2/2012 12:58, Andrey V. Elsukov wrote:
>>
>> On 30.04.2012 23:14, Adam Strohl wrote:
>>>
>>> da0 at tws0 bus 0 scbus0 target 0 lun 0
>>> da0:<LSI 9750-8i    DISK 5.12>  Fixed Direct Access SCSI-5 device
>>> da0: 6000.000MB/s transfers
>>> da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C)
>>>
>>>
>>> Let me know anyone wants to see anything else/has seen this/has any
>>> theories!
>>
>>
>> Can you try patch from the r234693, update and reinstall gptboot, does it
>> help?
>>        http://svnweb.freebsd.org/base?view=revision&revision=234693
>>

Did you try to repair the header ? I saw a similar issue on upgraded
boxes that were 7-STABLE upgraded to 9-STABLE. and recovering made the
warning go away . I may be way off here but just my 2 cents .

% gpart recover da0




--
mark saad | none...@longcount.org


--
mark saad | none...@longcount.org

[Adam Strohl]

On 5/2/2012 23:08, Andrey V. Elsukov wrote:
> On 02.05.2012 17:53, Adam Strohl wrote:
>>> % gpart recover da0
>>
>> Good thought, but no dice:
>>
>> $ gpart recover da0
>> da0 recovering is not needed
>
> I already saw several reports about gptboot's complains on 3ware
> controllers, but don't know what is the problem.
> The only guess is that a controller incorrectly handles BIOS requests,
> when gptboot tries to read GPT header from the end of a large virtual disk.


Thanks for your input on this Andrey. Just to clarify I am assuming
that "da0 recovering is not needed" means that gpart has no problem
reading and verifying the backup GPT header?

(which is why its probably the BIOS for the RAID controller as the GPT
is actually intact)