Skip site navigation (1)Skip section navigation (2)
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>