Safe way to repair corrupted GPT partition table?

[Bob Willcox]

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 now get these errors whenever I boot the system:

GEOM: da0: corrupt or invalid GPT detected.
GEOM: da0: GPT rejected -- may not be recoverable.

Fortunately, my ZFS filesystem on the disk (actually a RAID 5 array on a
ARC-1223 adapter) still mounts and seems to be ok. There is only one partition
on the disk (the ZFS one) and it covered the entire disk so restoring it
should be easy. Question is, is there a way to do this and will it be safe (I
wouldn't want to trash the filesystem in the partion).

A 'gpart show da0' gives this result:

gpart: No such geom: da0.

This is on a 9.1-STABLE system:

FreeBSD rancor.immure.com 9.1-STABLE FreeBSD 9.1-STABLE #2 r245176: Tue Jan 8 15:45:29 CST 2013 b...@amidala.immure.com:/usr/obj/usr/src/sys/AMIDALA amd64


Any help would be much appreciated.

--
Bob Willcox | LIVING YOUR LIFE:
b...@immure.com | A task so difficult, it has never been attempted before.
Austin, TX |
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Erich Dollansky]

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.

Erich

[ill...@gmail.com]

On 18 January 2013 15:08, 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 now get these errors whenever I boot the system:
>
> GEOM: da0: corrupt or invalid GPT detected.
> GEOM: da0: GPT rejected -- may not be recoverable.
>
> Fortunately, my ZFS filesystem on the disk (actually a RAID 5 array on a
> ARC-1223 adapter) still mounts and seems to be ok. There is only one partition
> on the disk (the ZFS one) and it covered the entire disk so restoring it
> should be easy. Question is, is there a way to do this and will it be safe (I
> wouldn't want to trash the filesystem in the partion).
>
> A 'gpart show da0' gives this result:
>
> gpart: No such geom: da0.
>
> This is on a 9.1-STABLE system:
>
> FreeBSD rancor.immure.com 9.1-STABLE FreeBSD 9.1-STABLE #2 r245176: Tue Jan 8 15:45:29 CST 2013 b...@amidala.immure.com:/usr/obj/usr/src/sys/AMIDALA amd64
>
>
> Any help would be much appreciated.
>

Is the whole disk in the zfs pool, or is this a
single partition covering the whole disk that
has been placed in the zfs pool?

Have you tried to repair it with the zfs tools?

--
--

[Bob Willcox]

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.)

Thanks,
Bob

>
> Erich

--
Bob Willcox | LIVING YOUR LIFE:
b...@immure.com | A task so difficult, it has never been attempted before.
Austin, TX |

[Bob Willcox]

On Fri, Jan 18, 2013 at 07:40:59PM -0500, ill...@gmail.com wrote:

> On 18 January 2013 15:08, 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 now get these errors whenever I boot the system:
> >
> > GEOM: da0: corrupt or invalid GPT detected.
> > GEOM: da0: GPT rejected -- may not be recoverable.
> >
> > Fortunately, my ZFS filesystem on the disk (actually a RAID 5 array on a
> > ARC-1223 adapter) still mounts and seems to be ok. There is only one partition
> > on the disk (the ZFS one) and it covered the entire disk so restoring it
> > should be easy. Question is, is there a way to do this and will it be safe (I
> > wouldn't want to trash the filesystem in the partion).
> >
> > A 'gpart show da0' gives this result:
> >
> > gpart: No such geom: da0.
> >
> > This is on a 9.1-STABLE system:
> >
> > FreeBSD rancor.immure.com 9.1-STABLE FreeBSD 9.1-STABLE #2 r245176: Tue Jan 8 15:45:29 CST 2013 b...@amidala.immure.com:/usr/obj/usr/src/sys/AMIDALA amd64
> >
> >
> > Any help would be much appreciated.
> >
>
> Is the whole disk in the zfs pool, or is this a
> single partition covering the whole disk that
> has been placed in the zfs pool?

It is a single partition covering the entire disk.

>
> Have you tried to repair it with the zfs tools?

No, not sure what to try. I'm fairly new to zfs.

Thanks,
Bob

>
> --
> --

[Warren Block]

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.

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.

[Erich Dollansky]

Hi,

On Sat, 19 Jan 2013 08:59:07 -0600

Bob Willcox <b...@immure.com> 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.)
>

this does not make it easier. What really helps is to copy first the
first the data you want to edit to a file and work then with the copy
of the file.

This enables you to copy the original back as often as you need.
Just make sure that you do not lose this copy. This will be the most
important file of all your files.

I used a normal thumb drive to play around before I went once to a hard
disk. Ok, there is a bit of sweat on your fingers, but the rest will be
ok.

Erich

[Bob Willcox]

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 |

[sciza...@gmail.com]

Hi you may once try with this partition recovery software. It can help you
to recover all sort of data from corrupted or lost partition. It helped me
lot to recover my data from lost partition. It works really well to all
kind of partition. For more details visit the link-
http://www.macpartitionrecovery.com/corrupted.html