On Mon, 20 Mar 2017 19:08:41 -0700
"Chris H" <bsd-li...@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%
> GEOM: diskid/DISK-E600665E1DC77749: the secondary GPT table is corrupt or
> GEOM: diskid/DISK-E600665E1DC77749: using the primary only -- recovery
> But why?
> This is on:
> FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700: amd64
> Thanks for any information.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@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).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"