Date: Sun, 20 Jan 2013 08:56:22 -0600 From: Bob Willcox <bob@immure.com> To: Warren Block <wblock@wonkity.com> Cc: Erich Dollansky <erichsfreebsdlist@alogt.com>, questions list <freebsd-questions@freebsd.org> Subject: Re: Safe way to repair corrupted GPT partition table? Message-ID: <20130120145622.GD7788@rancor.immure.com> In-Reply-To: <alpine.BSF.2.00.1301191710370.6961@wonkity.com> References: <20130118200824.GA4084@rancor.immure.com> <20130119072509.2579dcce@X220.ovitrap.com> <20130119145907.GA7788@rancor.immure.com> <alpine.BSF.2.00.1301191710370.6961@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <bob@immure.com> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130120145622.GD7788>