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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
