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

On Thursday, June 14, 2012 8:11:11 am Andrey V. Elsukov wrote:
> On 10.06.2012 17:48, Hiroki Sato wrote:
> > 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.
> 
> Hi,
> 
> I have tested your patch and discovered yet another problem.
> Actually the loader(8) doesn't read backup GPT header and table and
> this stops booting when primary header or table damaged
> (pmbr and gptboot works as expected in this case).
> The libi386/biosdisk.c should be modified to add this support.
> 
> Also, our PMBR image doesn't contain any partition entries and
> writing it to the disk with dd(1) makes the system unbootable.
> What you think if we will add one partition entry to the PMBR image?
> I modified your patch (the last hunk added) and it is attached.

That is on purpose.  It is the responsibility of gpart to create the partition 
entry, not to hardcode one in pmbr.S.  You aren't supposed to dd pmbr to the 
disk, but use gpart to install it as bootcode.

-- 
John Baldwin