Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2012 08:50:20 +0400
From:      "Andrey V. Elsukov" <bu7cher@yandex.ru>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Doug Rabson <dfr@freebsd.org>, Marcel Moolenaar <marcel@FreeBSD.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <4FEA910C.4090305@yandex.ru>
In-Reply-To: <201206261337.11741.jhb@freebsd.org>
References:  <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FEA910C.4090305>