CFR: backup GPT header support in pmbr and loader(8) (Re: Handbook mirroring section)

[move from -doc_at_ to -current_at_]

"Andrey V. Elsukov" <ae_at_FreeBSD.org> wrote
  in <4FD05573.70801_at_FreeBSD.org>:

ae> On 06.06.2012 15:07, Hiroki Sato wrote:
ae> > ae> 1. When geom_mirror module is not loaded GEOM_PART will complain that the
ae> > ae> backup GPT header is not in the last LBA and partition table will be marked
ae> > ae> as CORRUPT. The recover operation will destroy the GEOM_MIRROR's metadata.
ae> > ae>
ae> > ae> 2. If primary GPT header or table become damaged, then gptboot will not
ae> > ae> detect GPT because the backup GPT header is not in the last LBA. So, the
ae> > ae> system will not boot.
ae> >
ae> >  Thanks, I see.  Do you think the attached patch is too aggressive for
ae> >  the problem 2?  The value of altlba should be matched with one in the
ae> >  original secondary header when the primary header is corrupted and
ae> >  the secondary header is looked up in this way.
ae>
ae> Yes, i also have thought about this and this should work for most GEOM classes,
ae> but i revised again PMBR code and it seems that it will not work anyway :)
ae> Our PMBR doesn't use backup GPT header and table, and it doesn't verify
ae> correctness of primary GPT.
ae>
ae> From the other side, there are three situations when we use GPT:
ae> 1. FreeBSD is only one system on the disk and we use PMBR and gptboot to boot it.
ae>
ae> In case if we will fix PMBR your patch will help.

 I created the attached patchset for the loader and pmbr to support
 backup GPT header when the primary one is corrupted.  Can anyone test
 and/or review it?

 The pmbr program now checks the GPT signature, and if failed it tries
 to search the backup header from the last LBA.  When GEOM metadata is
 found at the last LBA, the second last will be checked.  The
 loader(8) program also supports the same algorithm to search the
 backup header.

ae> 2. FreeBSD is no one on the disk, but we still use legacy boot method (PMBR+gptboot).
ae>
ae> I don't know what behavior have other systems when they detect invalid GPT (i.e.
ae> when backup header is not in the last LBA).
ae>
ae> 3. We use UEFI (it is not work yet).
ae>
ae> Also i don't know what UEFI firmware will do with invalid GPT.

 I am investigating how Windows and other UEFI-based software
 recognize the backup header now.  Hopefully they use the alternative
 LBA field and do not unconditionally overwrite the last LBA for
 recovering.  Probably it is difficult to make UEFI recognize the
 backup header that is not located at the last LBA when the primary
 header is corrupted.

-- Hiroki