From owner-freebsd-current@freebsd.org Tue Mar 21 05:16:21 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 88EDCD15FAF for ; Tue, 21 Mar 2017 05:16:21 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8F587A for ; Tue, 21 Mar 2017 05:16:20 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LZzKf-1cTCg40nrJ-00ljIx; Tue, 21 Mar 2017 06:16:05 +0100 Date: Tue, 21 Mar 2017 06:16:03 +0100 From: "O. Hartmann" To: "Chris H" Cc: "FreeBSD CURRENT" 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> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D3jbmfa7d0XvX6JemfmlP1VrBNKLuy+ELMIfmbeCB1E8qvtpVLG iz1w2ine7Az9CvdwtRhtdInImefdCWR5vMquWAgI4v2xZ+MttGcwqTjxgCaVU2kvNmcWuq/ M/mgWQezdFfMOJXXLIPQttyPPecwXu5hZjTT/4yEIXK+dwgOwldrh/vSijRIYpQOY2sJ5ok wwSgiWfbkRaHbYzaG5YCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:At3hG7OS7uQ=:gBEc5NHIAoILObmGB3AffI IkMU/7BHEI6a4LyKsfdobCT5HOdtdMB1nh6eUQahV+KEdc1SXhxCLe7Fyp/J5G4NTO6jo53Pv ei/XDMdfpCWA0JFCcggg3nKvtg5P9QJ2PRyF9PJ01oauUd2ghBynGRcDu1a3yPes9Ok6o2lqO Dwm0w/2kcZXLlxZMF0mBqu5Ev62RJUzeFY7Nh2Ezl43aFO1BDGSBH58wkVmUKB1VIYujv9Fy7 9j0NfA02hkulda7XR1p7b/jGBseJDM3EY3mFryPhsHrvvU3Sg+u959qKKQZtDlFsfPmeAv1MZ lrwSKL55AQEB112M6Pa4CMMc5AjrF5e5OseHwiRivFGy2sa0leehBt10u8EPZ8XuJsZR6+btx YkqyFlwk0aPql/ns/6YshUuF6y3gJr5JfRDvugDq9+DmVPjKRr7S/NdtZrhAukPwupkRmY4ow F424Dy0al1IaVoTZSS/nuDrGStNkaAj2sLBPGwGYcVqdDbwLS/C1P3601PGM81ZjILn3HgMTc ViGdvV2soY1xVuB+ixNoq2L/gM4XaPCldteWHqIvW4/wkZFbNHtPgMcEcAPr60sXtkIV42w70 7RNxI0GQ03IAu1EgFEEl+w7ym3bDlD8rcshyS2fw/yDl20vF4XQGMmJv1CAPHOFx23lS4HXsU LW4zfiVt7YLlF2IHkYTu2389J8gGdEeEu/GDqpZRMIZWi9H6QeSxiZSfdmykVrWqbFRAHtlah 8ckc1NEeZt20UwIHcfPguKmxv25hpaATfNOkEFK/Mzz9pKi31zXPcLz00tY6JDHO+ZS0FHxuC yvrtHgM X-Mailman-Approved-At: Tue, 21 Mar 2017 11:03:59 +0000 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:16:21 -0000 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 > > > _______________________________________________ > 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