Date: Tue, 01 May 2012 02:14:15 +0700 From: Adam Strohl <adams-freebsd@ateamsystems.com> To: FreeBSD-Stable ML <freebsd-stable@freebsd.org> Subject: FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though) Message-ID: <4F9EE487.6020609@ateamsystems.com>
next in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F9EE487.6020609>