From owner-freebsd-questions@FreeBSD.ORG Sun Jan 20 00:19:12 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B18FB2A4 for ; Sun, 20 Jan 2013 00:19:12 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5A271E for ; Sun, 20 Jan 2013 00:19:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0K0J49h006980; Sat, 19 Jan 2013 17:19:04 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0K0J3xt006977; Sat, 19 Jan 2013 17:19:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 19 Jan 2013 17:19:03 -0700 (MST) From: Warren Block To: Bob Willcox Subject: Re: Safe way to repair corrupted GPT partition table? In-Reply-To: <20130119145907.GA7788@rancor.immure.com> Message-ID: References: <20130118200824.GA4084@rancor.immure.com> <20130119072509.2579dcce@X220.ovitrap.com> <20130119145907.GA7788@rancor.immure.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 19 Jan 2013 17:19:04 -0700 (MST) Cc: Erich Dollansky , questions list X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 00:19:12 -0000 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. 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. 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.