From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 04:50:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8752106566B; Wed, 27 Jun 2012 04:50:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id E40748FC16; Wed, 27 Jun 2012 04:50:28 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward5.mail.yandex.net (Yandex) with ESMTP id 3049C1202173; Wed, 27 Jun 2012 08:50:27 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772627; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=V0KMa3FlUKD5mTLAcU+DGAQJXYdIiIw66qZ4EYkP2ENJSLs/dCDYH+P5UPN7yWKDa UNSXrBrmWM2o9so7ozQBwzMu8QBAhj+T0rDHxc2y2fr6wUzcQzzTtrPDcREVWj8vwj +dBaRQtp3iER7uxC/cRlgLIXqLOY+9vaplEcU198= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id A54C95C03D0; Wed, 27 Jun 2012 08:50:26 +0400 (MSK) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id oQF8H3nW-oQFuT0r9; Wed, 27 Jun 2012 08:50:26 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@FreeBSD.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340772626; bh=Jcum2yLgZon2uNC2jfVxqj1hN+QO9Z8Z8GgH7dkljyw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type; b=SHkEl6mwykxDo2ZsiFh65M8SWNef1ho1iHRzLpO3kdj3UED58Q8OiuLhUDBo6yeEp 940qifykcM1LD2heDWry4ceIj6HnkjryD+G0Y/RsLjwHolF0iMHa1MBqTwMdBYhvpk 7WXif3IIHm6L4vki3NL0boSRicURNVGREWfQQPtI= Message-ID: <4FEA910C.4090305@yandex.ru> Date: Wed, 27 Jun 2012 08:50:20 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> In-Reply-To: <201206261337.11741.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig43DFB080B9C277186794B58A" 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 04:50:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig43DFB080B9C277186794B58A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 als= o >> 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. 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." For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our l= oader for the better supporting of our technologies. 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. >> 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 recor= d >> 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. 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. --=20 WBR, Andrey V. Elsukov --------------enig43DFB080B9C277186794B58A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJP6pERAAoJEAHF6gQQyKF6pPkH/iWeqKnlQRc7jDKVoWb8iabJ 1lmJ+cv96Ypq+DoTVaRwrRCQIRt3z2E3l4IUVgKFnJODSZt6G2Grl7IjOwD5aZ90 fU7d5qIRWih3t+w6+zH9yFzPbzc4aq/CV/7fFlrtjXSaYFe7PqEYLFxtg32prGch Jd9kqSOq0mDnue0hPfTFHgHmG3gGh+eQ3Kffs6rDMEMMArMKP7xEunESAsfO7Rl8 2EBbnP2Wz8unzqwRO+Z2gAbyTHyNRjkVVs0mzsLiFseCxdPnIOkGMYLOx9bCOwNs AUASvIYDrB9waAK59NS8S3xnw8F/F81lT2i+GWvhvsNtQWMk5kXbLWjr1i9AmV4= =9ix4 -----END PGP SIGNATURE----- --------------enig43DFB080B9C277186794B58A--