From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 12:22:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A779310657A9; Wed, 27 Jun 2012 12:22:49 +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 75B5A8FC14; Wed, 27 Jun 2012 12:22:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB131B945; Wed, 27 Jun 2012 08:22:48 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Wed, 27 Jun 2012 08:07:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> In-Reply-To: <4FEA910C.4090305@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206270807.23347.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Jun 2012 08:22:48 -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-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:22:49 -0000 On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote: > On 26.06.2012 21:37, John Baldwin wrote: > >> 4. The gptboot now searches the backup GPT header in the previous sect= ors, > >> when it finds the "GEOM::" signature in the last sector. PMBR code also > >> tries to do the same: > >> common/gpt.c > >> i386/pmbr/pmbr.s > >=20 > > GPT really wants the backup header at the last LBA. I know you can set= it,=20 > > but I've interpreted that as a way to see if the primary header is corr= ect or=20 > > not. It seems to me that GPT tables created in this fashion (inside a = GEOM=20 > > provider) will not work properly with partition editors for other OS's.= I'm=20 > > hesitant to encourage the use of this as I do think putting GPT inside = of a=20 > > gmirror violates the GPT spec. >=20 > The standard says: > "The following test must be performed to determine if a GPT is valid: > =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 the = 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 de= vice to see if it has a > valid GPT Header and point to a valid GPT Partition Entry Array." 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. > If a user wants modify GPT in the disk editor from the another OS, > he can do it, and it should work. The result depends only from the partit= ion editor, > it might overwrite the last sector and might don't. I would not assume it would work at all. If it can't trust the primary GPT, it has to assume the alternate is at the last LBA. > >> 5. Also the pmbr image now contains one fake partition record. > >> When several first sectors are damaged the kernel can't detect GPT > >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(= 1) > >> command, but the old pmbr image has an empty partition table and > >> loader doesn't able to boot from GPT, when there is no partition record > >> in the PMBR. Now it will be able. When pmbr is installed via 'gpart=20 > > bootcode' > >> command, the kernel correctly modifies this partition record. So, this= is=20 > > only > >> for the first rescue step. > >=20 > > As I said earlier, I do not think this is appropriate and that instead > > gpart should have an appropriate 'recover' command to install just the = pmbr on=20 > > a disk and also create a correct entry in the MBR if needed while doing= so. >=20 > gpart(8) is only one of several geom(8)' tools to manage objects of a GEO= M class. > It only sends control requests to the kernel. If GPT is not detected, > there is no geom objects to manage. And we can't write bootcode with gpar= t(8). > I think that adding such functions to the gpart(8) is not good. Maybe, > the boot0cfg is the better tool for that. Also we still haven't any tool = to > install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' comma= nd does? Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even thou= gh there isn't a GPT object yet. =2D-=20 John Baldwin