Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
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) ___ 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
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On 30.04.2012 23:14, Adam Strohl wrote: da0 at tws0 bus 0 scbus0 target 0 lun 0 da0: LSI 9750-8iDISK 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=revisionrevision=234693 -- WBR, Andrey V. Elsukov ___ 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
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
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-8iDISK 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=revisionrevision=234693 ___ 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
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On Wed, May 2, 2012 at 5:03 AM, Adam Strohl adams-free...@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=revisionrevision=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 | nones...@longcount.org -- mark saad | nones...@longcount.org ___ 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
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
On 5/2/2012 20:46, Mark Saad wrote: 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 Good thought, but no dice: $ gpart recover da0 da0 recovering is not needed ___ 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
Re: FreeBSD 9 gptboot: invalid backup GPT header error (boots fine though)
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. -- WBR, Andrey V. Elsukov ___ 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
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 0xb194-0xb1943fff,0xb190-0xb193 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-8iDISK 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
