New BSD Installer

Andriy Gapon avg at
Fri Feb 17 15:43:35 UTC 2012

on 17/02/2012 16:28 Hiroki Sato said the following:
> Andriy Gapon <avg at> wrote
>   in <4F3E3000.9000206 at>:
> 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

More information about the freebsd-stable mailing list