New BSD Installer

[Andriy Gapon]

on 17/02/2012 16:28 Hiroki Sato said the following:
> Andriy Gapon <avg at FreeBSD.org> wrote
>   in <4F3E3000.9000206 at FreeBSD.org>:
> 
> av> -----BEGIN PGP SIGNED MESSAGE-----
> av> Hash: SHA1
> av>
> av> on 17/02/2012 09:04 Hiroki Sato said the following:
> av> > No, the issue is our gptloader assumes the backup header is always located
> av> > at the (physical) last sector while this is not mandatory in the UEFI
> av> > specification.
> av>
> av> Are you sure?
> 
>  Yes, sure.

Sorry, I haven't really given a thought to what you wrote below.
You said that "this is not mandatory in the UEFI specification" and I gave the
quotes which say that it is.  Also keep in mind that BIOS and other OSs know
nothing about FreeBSD GEOM.

> In the gm0->md0+md1 case, the last LBA of the "device" is
>  changed (growed in size) but they can still have a valid backup
>  header at "the last LBA - 1" before an attempt to grow the size of
>  the volume as the last paragraph of your excerpts says.  If we
>  *choose* to grow the device size permanently, the backup header must
>  be relocated at the new last LBA.  However, before the relocation
>  happens, the specification says both the primary and secondary header
>  must be valid in the previous device size.  This is my understanding.
> 
>  This means software should assume the device size can grow and should
>  not assume the backup header is always located at the last possible
>  LBA on the device.  If AlternateLBA does not match "the device size -
>  1", the software should recognize the location of the backup header
>  based on the information in the primary header first.  The gptboot
>  does not do so currently.  I didn't give it a try actually but the
>  attached patch is what I want to say.
> 
> -- Hiroki


-- 
Andriy Gapon