Date: Tue, 21 Mar 2017 06:16:03 +0100 From: "O. Hartmann" <o.hartmann@walstatt.org> To: "Chris H" <bsd-lists@bsdforge.com> Cc: "FreeBSD CURRENT" <freebsd-current@freebsd.org> Subject: Re: why are the GEOM secondary GPT tables always corrupt? Message-ID: <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net> References: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Mar 2017 19:08:41 -0700 "Chris H" <bsd-lists@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170321061603.73929f93>