Re: [CFC/CFT] large changes in the loader(8) code

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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"