Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Mar 2017 22:35:42 -0700
From:      "Chris H" <bsd-lists@bsdforge.com>
To:        "O. Hartmann" <o.hartmann@walstatt.org>
Cc:        "FreeBSD CURRENT" <freebsd-current@freebsd.org>
Subject:   Re: why are the GEOM secondary GPT tables always corrupt?
Message-ID:  <c458b146a1b538d4aa40af2ae6b7211e@ultimatedns.net>
In-Reply-To: <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de>
References:  <55f81bad1176cc0135610f56549e85aa@ultimatedns.net>, <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Mar 2017 06:16:03 +0100 "O. Hartmann" <o.hartmann@walstatt.org>
wrote

> 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
> 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

Thanks for the reply.
Yes, I've caught that too. But that /almost/ seems reasonable, for
that circumstance. What concerns me here; is that this is a fresh
partition && newfs. Given the partition spans the entire flash
drive. I wouldn't expect there to be any inconsistencies between
the 2 records. I'd hate to use the recover option, and have it
use wrong results. Why isn't the second table "synced" with the
first/primary table?
I'd blame it on the flash drive, but it's not limited to just
this drive, nor just this box. I have a version 11 box that's some
6mos out, that also does this.

Thanks again, for taking the time to reply!

--Chris





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c458b146a1b538d4aa40af2ae6b7211e>