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 <b...@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: b...@immure.com | A task so difficult, it has never been attempted before. Austin, TX | _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
