From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 06:57:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A792106566B for ; Tue, 17 Nov 2009 06:57:31 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4078FC12 for ; Tue, 17 Nov 2009 06:57:30 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id nAH6vSHl045392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2009 07:57:28 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Tue, 17 Nov 2009 07:57:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE2E5E5-B6A4-4870-A346-ABC1CD20EE34@lassitu.de> References: To: Jeremy Thornhill X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: "corrupt or invalid GPT" when attempting to import Solaris ZFS pool (8.0-RC3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 06:57:31 -0000 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: >=20 > 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=3D/dev/zero of=3D/dev/da0 count=3D34 However, I'd expect this to have no effect on zpools ability to import = the pool. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811