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
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
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
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
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:
$
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
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