From owner-freebsd-questions@freebsd.org Sun Jun 28 06:52:41 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8C0998F9F2 for ; Sun, 28 Jun 2015 06:52:41 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from douhisi.pair.com (douhisi.pair.com [209.68.5.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88F801072 for ; Sun, 28 Jun 2015 06:52:41 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from [10.2.2.1] (pool-173-48-121-235.bstnma.fios.verizon.net [173.48.121.235]) by douhisi.pair.com (Postfix) with ESMTPSA id 6D0123F6EA for ; Sun, 28 Jun 2015 02:52:39 -0400 (EDT) Message-ID: <558F99B6.2080205@sneakertech.com> Date: Sun, 28 Jun 2015 02:52:38 -0400 From: Quartz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-questions Subject: Re: Corrupt GPT on ZFS full-disks that shouldn't be using GPT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 06:52:41 -0000 > 3. dmesg reports "the primary GPT table is corrupt or invalid" and > "using the secondary instead -- recovery strongly advised." > Q: How can I remove the secondary GPT table from each of the drives > that are participating in the zpool? First off, you should double check what's going on with your layout. You didn't mention what system you're running or how this array was created. In several cases even if you meant to use the whole disk you can accidentally or unknowingly end up making gpt headers anyway, either for labels, compatibility, or because you did something that ended up requiring partitions. Also, a lot of zfs-based front ends (eg; freenas) always create zfs-on-partitions, so if this array was ported from another system it's possible it's supposed to have a legit gpt layout. Additionally, some motherboards and expansion cards that offer raid services can cause problems that can screw with gpt. I have a motherboard where I have to set the sata ports as old style ide compatible, because turning on ahci mode automatically reserves/locks off a chunk of the end of the disk for raid metadata (even if I have the raid options disabled) causing dmesg to complain about corrupt gpt headers. So double check if you've changed anything related to that. Either way, before you go any further, explain the steps you did to create this pool and dump out everything that the gpt commands tell you about the disks. It would especially help to get a dump of either/both headers to see what's going on there. >I suppose I could offline and > resilver each of them. Simply resilvering is not guaranteed to fix the problem, depending on what's going on. If you're feeling adventurous you can always offline a drive and 'gpart destroy' it, then see what zfs says if you try to bring it back or reboot. > I'm afraid to dd the secondary GPT header at > the last 512 bytes of the drive. Perhaps there is a way I can ask ZFS > to do that for me? Zfs doesn't mess with gpt directly like that, so no. If you don't want to 'gpart destroy' it for some reason it's not hard to nuke it yourself though with dd; you just need the output from 'diskinfo' and a calculator.