why are the GEOM secondary GPT tables always corrupt?

[O. Hartmann]

On Mon, 20 Mar 2017 19:08:41 -0700
"Chris H" <bsd-lists at bsdforge.com> wrote:

> I've seen this discussed before, but there were so many
> "solutions", I was left feeling this *must* be some sort
> of bug in GEOM/gpart. So. I just blew away the tables on
> a USB3 flash drive:
> 
> # gpart destroy -F da0
> 
> # gpart create -s gpt da0
> 
> # gpart add -t freebsd-ufs -l jails da0
> 
> # newfs -U /dev/gpt/jails
> 
> Added an entry to fstab(5)
> OK this should be good to go. Mount, and umount
> all return as expected, as does fsck(8).
> 
> Upon reboot, I receive the following:
> 
> /dev/gpt/jails: clean, 29961779 free (27 frags, 3745219 blocks, 0.0%
> fragmentation)
> GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or
> invalid.
> GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery
> suggested.
> 
> But why?
> 
> This is on:
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64
> 
> Thanks for any information.
> 
> --Chris
> 
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

I see this when I put a disk image, which is smaller than the entire device
(for instance, 8GB USB flash drive with a UEFI booting (GPT) NanoBSD image of 1
GB in size. I do not know what exactly causes the problem, but it can be fixed
by issuing "gpart recover DEV". I think the secondary GTP table is supposed to
reside on the physically last blocks of the device (physically).

oh