Safe way to repair corrupted GPT partition table?
Bob Willcox
bob at immure.com
Sun Jan 20 14:56:51 UTC 2013
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 at 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 at immure.com | A task so difficult, it has never been attempted before.
Austin, TX |
More information about the freebsd-questions
mailing list