From owner-freebsd-current@freebsd.org Tue Mar 21 05:35:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61103D16A91 for ; Tue, 21 Mar 2017 05:35:32 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26C5216AF for ; Tue, 21 Mar 2017 05:35:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2L5ZaV8002949; Mon, 20 Mar 2017 22:35:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: "O. Hartmann" Cc: "FreeBSD CURRENT" In-Reply-To: <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> References: <55f81bad1176cc0135610f56549e85aa@ultimatedns.net>, <20170321061603.73929f93@freyja.zeit4.iv.bundesimmobilien.de> From: "Chris H" Subject: Re: why are the GEOM secondary GPT tables always corrupt? Date: Mon, 20 Mar 2017 22:35:42 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 05:35:32 -0000 On Tue, 21 Mar 2017 06:16:03 +0100 "O. Hartmann" wrote > On Mon, 20 Mar 2017 19:08:41 -0700 > "Chris H" 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