From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 21:12:02 2012 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 396291065672; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 06BE38FC0C; Wed, 27 Jun 2012 21:12:02 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RLBqNW012645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 14:11:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB7181.9000508@yandex.ru> Date: Wed, 27 Jun 2012 14:11:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <658E457B-3107-4BE8-A8EE-4F97D021843E@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> <4FEB7181.9000508@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code 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: Wed, 27 Jun 2012 21:12:02 -0000 On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote: > On 28.06.2012 00:14, Marcel Moolenaar wrote: >>> Our loader detects that primary GPT header is damaged. It tries to read >>> backup GPT header from the last LBA and it detects that there is >>> "GEOM::" signature. It tries to read one previous sector and there is >>> *valid* GPT header. >> >> How do you know it's valid? It's in a location that is not valid >> to begin with. Validity is based on rules and you're violating the >> the rules without defining exactly what we call valid given the >> new rules. This may seem nitpicking, but having went through the >> hassle of dealing with the broken way we created the dangerously >> dedicated disk, I appreciate the importance of being anal when it >> comes to something that lives on non-volatile storage and gets to >> be exposed to a world much larger than FreeBSD. > > So why do you not prevent to attach GEOM_PART_GPT to any providers that > are not the disk drive? This will be the right solution to all our > problems. Just don't create invalid GPT. It's not even the right solution, as it prevents legit nesting of gpart GEOMs *and* is fundamentally based on a flawed assumption that any non-disk GEOM underneath gpart yields an invalid GPT. Think gnop. -- Marcel Moolenaar marcel@xcllnt.net