From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 19:54:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E269A106566B for ; Thu, 1 Sep 2011 19:54:59 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6BB8FC15 for ; Thu, 1 Sep 2011 19:54:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p81Jsw2R080242; Thu, 1 Sep 2011 13:54:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p81JswRf080239; Thu, 1 Sep 2011 13:54:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 1 Sep 2011 13:54:58 -0600 (MDT) From: Warren Block To: Garrett Cooper In-Reply-To: <24B9852A-8DE4-4BC6-9B55-2D74E414E31D@gmail.com> Message-ID: References: <24B9852A-8DE4-4BC6-9B55-2D74E414E31D@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 01 Sep 2011 13:54:58 -0600 (MDT) Cc: Jason Campbell , Matt Thyer , freebsd-current@freebsd.org Subject: Re: Problems booting 9.0-BETA1 memstick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 19:55:00 -0000 On Thu, 1 Sep 2011, Garrett Cooper wrote: > On Sep 1, 2011, at 12:00 PM, Matt Thyer wrote: > >> Shouldn't we use MBR partitioning instead of GPT for the memstick image ? >> >> We won't need larger than 2TiB installation media for many decades! > > Or just don't use a backup partition? Maybe dd conv=sync would help? It seems like the same problem as gmirror inside a GPT partition. gptboot doesn't realize it's looking for backup GPT data in the wrong spot. That might be a problem local to gptboot, or something deeper. It seems wrong to have gptboot just ignore backup GPT data, but it could be an option. Can it actually do something if the backup GPT differs, or is it testing for an error that can't be handled? MBR didn't have backup data ("Luxury! Pure luxury!"), and it did okay.