From owner-freebsd-questions@FreeBSD.ORG Sun Jan 20 14:56:51 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 480911CD for ; Sun, 20 Jan 2013 14:56:51 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by mx1.freebsd.org (Postfix) with ESMTP id DD2C9780 for ; Sun, 20 Jan 2013 14:56:49 +0000 (UTC) Received: from rancor.immure.com (rancor.immure.com [10.1.132.9]) by maul.immure.com (8.14.5/8.14.5) with ESMTP id r0KEuN0b070527; Sun, 20 Jan 2013 08:56:23 -0600 (CST) (envelope-from bob@immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.6/8.14.6) with ESMTP id r0KEuNwL012140; Sun, 20 Jan 2013 08:56:23 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.6/8.14.6/Submit) id r0KEuMn2012139; Sun, 20 Jan 2013 08:56:22 -0600 (CST) (envelope-from bob) Date: Sun, 20 Jan 2013 08:56:22 -0600 From: Bob Willcox To: Warren Block Subject: Re: Safe way to repair corrupted GPT partition table? Message-ID: <20130120145622.GD7788@rancor.immure.com> References: <20130118200824.GA4084@rancor.immure.com> <20130119072509.2579dcce@X220.ovitrap.com> <20130119145907.GA7788@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner-ID: r0KEuN0b070527 X-immure-MailScanner: Found to be clean X-immure-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 1, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-immure-MailScanner-From: bob@immure.com X-Spam-Status: No Cc: Erich Dollansky , questions list X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Bob Willcox List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 14:56:51 -0000 On Sat, Jan 19, 2013 at 05:19:03PM -0700, Warren Block wrote: > On Sat, 19 Jan 2013, Bob Willcox wrote: > > > On Sat, Jan 19, 2013 at 07:25:09AM +0700, Erich Dollansky wrote: > >> Hi, > >> > >> On Fri, 18 Jan 2013 14:08:25 -0600 > >> Bob Willcox wrote: > >> > >>> Is there a way to repair a GPT partition table that has gotten > >>> corrupted (following a system hang during heavy I/O to a ZFS > >>> filesystem)? > >>> > >> I would use a hex editor. Of course, try it out on another disk before > >> working on that disk. You can even copy the data with dd from the other > >> disk after you are sure it will work. Of course, the size must match or > >> must be made matching. > >> > >> Ok, it is not a safe way but it is a working way. > > > > Have to say I was hoping that there was some programatic way to do this. > > Certainly if I go down this path I'll have to practice on a disk that doesn't > > contain data that I care about. Getting the size right as this is the only > > disk of this size I have. (Actually, it's an Areca RAID 5 Volume Set.) > > If the primary table at the start of the disk is okay, 'gpart recover' > can copy it to the backup table at the end of the disk. I thought it > would do that the other way around also. Neither table should be > affected by a power failure, as they are almost never written. This wasn't a power outage, it was a system hang while I was copying data to the new zfs filesystem. It had been running for quite a while (couple of hours maybe) when it hung. I had created the partition table and zfs pool right before starting the copy. > > How it got into a state where it could be recognized as GPT but not > recoverable, don't know. Could be the disk device (ada0) was given to > ZFS rather than the partition (ada0p1). ZFS is supposed to leave some > space at the end of the disk to allow for slightly differing nominal > disk sizes, which could have left the backup GPT table intact. It's entirely possible that when I created the zfs pool in overwrote the GPT table since it wasn't till I had to reboot following the hang that the system complained. > > ZFS has its own metadata, so it's not necessary to partition a drive > with GPT unless you want to put more than one partition on it, or maybe > control the size of space used. If that's the case perhaps the only problem I have is that something in the system appears to believe that there should be a GPT partition table on the disk when there isn't one. Thanks for the insight. Maybe I can simply ignore the GEOM messages at boot. Bob -- Bob Willcox | LIVING YOUR LIFE: bob@immure.com | A task so difficult, it has never been attempted before. Austin, TX |