On Tue, 2009-11-17 at 07:57 +0100, Stefan Bethke wrote: > Am 17.11.2009 um 05:10 schrieb Jeremy Thornhill: > > > 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? 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 <rnoland_at_FreeBSD.org> FreeBSDReceived on Tue Nov 17 2009 - 16:20:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC