From owner-freebsd-stable@FreeBSD.ORG Wed May 9 12:14:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EEE106566C for ; Wed, 9 May 2012 12:14:31 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 676A28FC15 for ; Wed, 9 May 2012 12:14:31 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 26A64B9067; Wed, 9 May 2012 08:14:23 -0400 (EDT) Message-ID: <4FAA5F9F.1080203@ateamsystems.com> Date: Wed, 09 May 2012 19:14:23 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4F9EE487.6020609@ateamsystems.com> <4FA0CCF0.5000607@FreeBSD.org> <4FA0F872.4040008@ateamsystems.com> <4FA13C48.8010700@ateamsystems.com> <4FA15C0D.2050107@yandex.ru> In-Reply-To: <4FA15C0D.2050107@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 12:14:31 -0000 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)