From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 17:30:56 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 DF0AB1065673; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEBA48FC1F; Wed, 27 Jun 2012 17:30:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 21DBDB953; Wed, 27 Jun 2012 13:30:56 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 10:28:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> In-Reply-To: <4FEB0079.7050008@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206271028.54477.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 13:30:56 -0400 (EDT) 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 17:30:57 -0000 On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: > On 27.06.2012 16:07, John Baldwin wrote: > >> =E2=80=A2 Check the Signature > >> =E2=80=A2 Check the Header CRC > >> =E2=80=A2 Check that the MyLBA entry points to the LBA that contains t= he GUID Partition Table > >> =E2=80=A2 Check the CRC of the GUID Partition Entry Array > >> If the GPT is the primary table, stored at LBA 1: > >> =E2=80=A2 Check the AlternateLBA to see if it is a valid GPT > >> If the primary GPT is corrupt, software must check the last LBA of the= device to see if it has a > >> valid GPT Header and point to a valid GPT Partition Entry Array." > >=20 > > Right, we break the last rule. If you want to use a partition editor > > that doesn't grok gmirror (because you are using another OS's editor), > > to repair a GPT, it will do the wrong thing. >=20 > When we are in the FreeBSD, our loader can detect that device size > is lower than it see and it will work. When primary header is OK, then > other OSes should work with this GPT. When it isn't OK, you just can't > load other OS :) Ah, yes. The solution to violating standards is to make sure you never use standards-compliant software. That's a great argument. :) (Although not entirely uncommon. Standards aren't always perfect, but if we had a way to not gratuitously violate them it would be nice to avoid doing so.) > > We can't write bootcode with gpart? What do you think the 'bootcode' c= ommand > > does? >=20 > `gpart bootcode -b` reads file, creates ioctl request and sends this data= to > the GEOM_PART class. GEOM_PART receives the control request, checks the d= ata > and writes it to the provider. > `gpart bootcode -p` works like dd(1) and writes bootcode to the given par= tition. > gpart(8) haven't any knowledge about specific partitioning scheme. Correct, but in both cases it writes "bootcode". > > Also, there is no reason we can't have a 'recover' command that attempt= s to > > recover a corrupted table including repairing the PMBR. gpart(8) alrea= dy > > generates a full PMBR when you use 'gpart create' to create a GPT even = though > > there isn't a GPT object yet. >=20 > `gpart create` creates only ioctl control request to the GEOM_PART class. > GEOM_PART class creates new GPT geom object and this objects writes PMBR = and its > metadata to the provider. You can't add a new ioctl? =2D-=20 John Baldwin