"corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3)
Jeremy Thornhill
I've been trying out 8.0-RC3 on a spare machine. I've been hoping that
8.0 would be a good time to move my ZFS pools from an old Solaris x86
box to FreeBSD.
I've been testing the procedure with a USB drive which was allocated
as a single pool under Solaris. It's the correct filesystem version
(13). I export the pool from the Solaris box, and then attempt to
import it on the FreeBSD box. Unfortunately, I get the following
error, and the pool is not able to be imported:
GEOM: da0: corrupt or invalid GPT detected.
GEOM: da0: GPT rejected -- may not be recoverable.
I've seen some recent posts on the lists where a helpful developer
assisted a user suffering from a similar circumstance, but I wasn't
able to determine if there is a general way for users to resolve such
issues. If I understand correctly this is an incompatibility in how
Solaris partitions disks when they are allocated entirely to a pool.
So, before I attempt this full scale on my raidz array, can anybody
point me in the right direction to get beyond this error and make my
Solaris ZFS pools work in FreeBSD?
Thanks,
Jeremy
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Stefan Bethke
> I've been testing the procedure with a USB drive which was allocated
> as a single pool under Solaris. It's the correct filesystem version
> (13). I export the pool from the Solaris box, and then attempt to
> import it on the FreeBSD box. Unfortunately, I get the following
> error, and the pool is not able to be imported:
>
> GEOM: da0: corrupt or invalid GPT detected.
> GEOM: da0: GPT rejected -- may not be recoverable.
What error are you getting from zpool import?
I believe the GEOM error is due to Solaris adding the GPT partition table to the start of the device, but not the end. GEOM requires both copies to be present and identical, IIRC. Since the pool fills the device, there's no space at the end, so adding the second copy is not an option.
You could try destroying the first GPT copy by zeroing the first 34 blocks. I'm not sure what Solaris will make of the pool after this, though:
# dd if=/dev/zero of=/dev/da0 count=34
However, I'd expect this to have no effect on zpools ability to import the pool.
HTH,
Stefan
--
Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811
Jeremy Thornhill
>
> What error are you getting from zpool import?
>
Interestingly enough, no error. The pool itself just doesn't seem to exist:
$ zpool import freeagent
cannot import 'freeagent': no such pool available
> I believe the GEOM error is due to Solaris adding the GPT partition table to the start of the device, but not the end. GEOM requires both copies to be present and identical, IIRC. Since the pool fills the device, there's no space at the end, so adding the second copy is not an option.
>
> You could try destroying the first GPT copy by zeroing the first 34 blocks. I'm not sure what Solaris will make of the pool after this, though:
> # dd if=/dev/zero of=/dev/da0 count=34
>
> However, I'd expect this to have no effect on zpools ability to import the pool.
>
I attempted this and, as you expected, I was still unable to import
the pool. It still reports 'no such pool', although the GEOM messages
*seem* to be gone. Taking this drive back to my Solaris system now
results in the following output in dmesg when it is attached (though
it still seems to function):
primary label corrupt; using backup
Oddly the disk doesn't appear in the Solaris 'format' utility so I
can't restore the label from backup (or at least, I don't know how
to).
Thanks,
Jeremy
Robert Noland
> Dear list,
>
> I've been trying out 8.0-RC3 on a spare machine. I've been hoping that
> 8.0 would be a good time to move my ZFS pools from an old Solaris x86
> box to FreeBSD.
>
> as a single pool under Solaris. It's the correct filesystem version
> (13). I export the pool from the Solaris box, and then attempt to
> import it on the FreeBSD box. Unfortunately, I get the following
> error, and the pool is not able to be imported:
>
> GEOM: da0: corrupt or invalid GPT detected.
> GEOM: da0: GPT rejected -- may not be recoverable.
This should be fixed in -CURRENT. The issue seems to be that solaris
claims that the GPT header is 512 bytes, where we expected it to always
be 92 bytes. The fixes are slated to merge to 7/8 stable within a few
days, however they won't make it into 8.0.
robert.
> I've seen some recent posts on the lists where a helpful developer
> assisted a user suffering from a similar circumstance, but I wasn't
> able to determine if there is a general way for users to resolve such
> issues. If I understand correctly this is an incompatibility in how
> Solaris partitions disks when they are allocated entirely to a pool.
>
> So, before I attempt this full scale on my raidz array, can anybody
> point me in the right direction to get beyond this error and make my
> Solaris ZFS pools work in FreeBSD?
>
> Thanks,
> Jeremy
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Robert Noland <rno...@FreeBSD.org>
FreeBSD
Robert Noland
> Am 17.11.2009 um 05:10 schrieb Jeremy Thornhill:
>
> > as a single pool under Solaris. It's the correct filesystem version
> > (13). I export the pool from the Solaris box, and then attempt to
> > import it on the FreeBSD box. Unfortunately, I get the following
> > error, and the pool is not able to be imported:
> >
> > GEOM: da0: corrupt or invalid GPT detected.
> > GEOM: da0: GPT rejected -- may not be recoverable.
>
zpool import won't do anything until GEOM is able to probe the disks.
> I believe the GEOM error is due to Solaris adding the GPT partition table to the start of the device, but not the end. GEOM requires both copies to be present and identical, IIRC. Since the pool fills the device, there's no space at the end, so adding the second copy is not an option.
Incorrect, Both primary and secondary headers are present, the above
GEOM error is stating that ALL copies of GPT headers have been deemed
invalid.
> You could try destroying the first GPT copy by zeroing the first 34 blocks. I'm not sure what Solaris will make of the pool after this, though:
> # dd if=/dev/zero of=/dev/da0 count=34
Bad advice. This will will destroy your partition table and you likely
won't be able to recover the disk. It is possible to hex edit the
existing solaris headers to make this work on FreeBSD, though I have
committed a proper fix to -CURRENT.
> However, I'd expect this to have no effect on zpools ability to import the pool.
If GEOM can't figure out the disk structure, zpool / zfs are useless.
robert.
>
> HTH,
> Stefan
Robert Noland
> On Tue, Nov 17, 2009 at 1:57 AM, Stefan Bethke <s...@lassitu.de> wrote:
> >
> >
>
>
> $ zpool import freeagent
> cannot import 'freeagent': no such pool available
>
> >
> > # dd if=/dev/zero of=/dev/da0 count=34
> >
> >
>
> the pool. It still reports 'no such pool', although the GEOM messages
> *seem* to be gone. Taking this drive back to my Solaris system now
> results in the following output in dmesg when it is attached (though
> it still seems to function):
>
> primary label corrupt; using backup
Sigh, yes... you have now trashed you primary gpt table. PLEASE do not
go using dd to write stuff to your disks unless you a) know what your
doing or b) don't care if you trash your disks...
> Oddly the disk doesn't appear in the Solaris 'format' utility so I
> can't restore the label from backup (or at least, I don't know how
> to).
If is important... I can help you restore the primary header...
robert.
> Thanks,
> Jeremy
Jeremy Thornhill
> This should be fixed in -CURRENT. The issue seems to be that solaris
> claims that the GPT header is 512 bytes, where we expected it to always
> be 92 bytes. The fixes are slated to merge to 7/8 stable within a few
> days, however they won't make it into 8.0.
Great news, thanks!
> Sigh, yes... you have now trashed you primary gpt table. PLEASE do not
> go using dd to write stuff to your disks unless you a) know what your
> doing or b) don't care if you trash your disks...
>
Indeed, I did not really care much about this disk, it's only a
backup. I was using it as a dry run to see if I would encounter any
issues before moving the 'real' data, and it did this job admirably :)
> If is important... I can help you restore the primary header...
Thanks, the disk is just fine again. I managed to restore the backup
label using the Solaris system (after I RTFM'd on 'format').
Jeremy Thornhill
>
> This should be fixed in -CURRENT. The issue seems to be that solaris
> claims that the GPT header is 512 bytes, where we expected it to always
> be 92 bytes. The fixes are slated to merge to 7/8 stable within a few
> days, however they won't make it into 8.0.
>
>
In case anybody was curious, this change is apparently in STABLE now,
and I'm happy to report that it has resolved my issues. Thanks for the
heads up Robert.
Robert Noland
> On Tue, Nov 17, 2009 at 12:12 PM, Robert Noland <rno...@freebsd.org> wrote:
> >
> > This should be fixed in -CURRENT. The issue seems to be that solaris
> > claims that the GPT header is 512 bytes, where we expected it to always
> > be 92 bytes. The fixes are slated to merge to 7/8 stable within a few
> > days, however they won't make it into 8.0.
> >
> > robert.
> >
>
> In case anybody was curious, this change is apparently in STABLE now,
> and I'm happy to report that it has resolved my issues. Thanks for the
> heads up Robert.
Correct, I MFC'd it to 7/8 stable this morning.
robert.
> Jeremy
--
Robert Noland <rno...@FreeBSD.org>
FreeBSD
_______________________________________________