freebsd stable - Apr 2012 - FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though)

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/

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

-- 
WBR, Andrey V. Elsukov