From owner-freebsd-hardware@FreeBSD.ORG Sun Nov 2 14:16:08 2014 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA627F2E; Sun, 2 Nov 2014 14:16:08 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 81EB5A4D; Sun, 2 Nov 2014 14:16:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA2EG066008767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Nov 2014 07:16:00 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA2EFx5f008764; Sun, 2 Nov 2014 07:16:00 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 2 Nov 2014 07:15:59 -0700 (MST) From: Warren Block To: John Subject: Re: gptboot: invalid backup GPT header In-Reply-To: <20141101224426.GA69717@potato.growveg.org> Message-ID: References: <20141101224426.GA69717@potato.growveg.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 02 Nov 2014 07:16:00 -0700 (MST) Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 14:16:09 -0000 On Sat, 1 Nov 2014, John wrote: > Hello lists, > > Not sure if this is a hardware problem or a filesystem problem, so have > cc'd to freebsd-fs@ > > The "problem" is on newly-installed freebsd 10.1 RC3. I say "problem" in > inverted commas because it's not stopping it from booting and the server > seems to run allright, I'm wondering if it's anything to worry about. As > well as seeing gptboot: invalid backup GPT header *before* beastie > starts, I see the following in dmesg: > > GEOM: mfid1: corrupt or invalid GPT detected. > GEOM: mfid1: GPT rejected -- may not be recoverable. > > There are 4 disks installed - mfid0,1,2 & 3. mfid0 is a regular ufs gpt > based disk. mfid1,2 and 3 together form a zfs raidz array. A thread on > https://forums.freenas.org/index.php?threads/gpt-table-is-corrupt-or-invalid-error-on-bootup.12171/ > describes a similar problem - the thing is though the "erroring" disk is > not a GPT disk, and the one in the example was. > > # gpart list mfid1 > gpart: No such geom: mfid1. My guess is that mfid1 was used as a GPT disk before it was used for ZFS. Installing ZFS to the whole disk leaves an unused and apparently unwritten section at the end, so the backup GPT is still present in the last few blocks (usually 33 blocks, but not always). That is the "invalid backup GPT header". Clearing the last blocks will remove the warning, at least if the assumption is correct. ZFS is not supposed to be using the last portion of the disk(*) to make replacing disks of slightly different sizes easier. Still, I would back up either the whole array, the whole disk, or at least the last 33 blocks of mfid1 first. *: I don't know exactly how much of the last part of the disk is not used by ZFS, do not recall an exact number being posted, and have not gone spelunking through the code for it. From owner-freebsd-hardware@FreeBSD.ORG Mon Nov 3 01:44:00 2014 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C705AC98; Mon, 3 Nov 2014 01:44:00 +0000 (UTC) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 86A38EB; Mon, 3 Nov 2014 01:44:00 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xl6gI-000OSf-1H; Mon, 03 Nov 2014 01:43:42 +0000 Date: Mon, 3 Nov 2014 01:43:41 +0000 From: John To: freebsd-hardware@freebsd.org, freebsd-fs@freebsd.org Subject: Re: gptboot: invalid backup GPT header Message-ID: <20141103014341.GA91255@potato.growveg.org> Mail-Followup-To: freebsd-hardware@freebsd.org, freebsd-fs@freebsd.org References: <20141101224426.GA69717@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 01:44:00 -0000 On Sun, Nov 02, 2014 at 07:15:59AM -0700, Warren Block wrote: > Clearing the last blocks will remove the warning, at least if the > assumption is correct. ZFS is not supposed to be using the last > portion of the disk(*) to make replacing disks of slightly different > sizes easier. Still, I would back up either the whole array, the > whole disk, or at least the last 33 blocks of mfid1 first. Thanks for replying. So, in short - is my data on the array in any danger, or is this just a cosmetic issue? [I think the reason it happened is that during the install process, where the installer asks you to choose partitions, I removed *everything* from mfid1,2 & 3 as I knew zfs likes to deal with the raw disk. I don't want to have to blat the system again though, unless absolutely necessary]. -- John From owner-freebsd-hardware@FreeBSD.ORG Mon Nov 3 04:46:36 2014 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D75128C7; Mon, 3 Nov 2014 04:46:36 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89164365; Mon, 3 Nov 2014 04:46:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sA34PbKH024525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Nov 2014 21:25:38 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sA34Pbum024495; Sun, 2 Nov 2014 21:25:37 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 2 Nov 2014 21:25:37 -0700 (MST) From: Warren Block To: John Subject: Re: gptboot: invalid backup GPT header In-Reply-To: <20141103014341.GA91255@potato.growveg.org> Message-ID: References: <20141101224426.GA69717@potato.growveg.org> <20141103014341.GA91255@potato.growveg.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 02 Nov 2014 21:25:38 -0700 (MST) Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 04:46:36 -0000 On Mon, 3 Nov 2014, John wrote: > On Sun, Nov 02, 2014 at 07:15:59AM -0700, Warren Block wrote: >> Clearing the last blocks will remove the warning, at least if the >> assumption is correct. ZFS is not supposed to be using the last >> portion of the disk(*) to make replacing disks of slightly different >> sizes easier. Still, I would back up either the whole array, the >> whole disk, or at least the last 33 blocks of mfid1 first. > > Thanks for replying. So, in short - is my data on the array in any > danger, or is this just a cosmetic issue? If the guess is correct, it's just cosmetic. Unless someone panics at the warning and tries to repair it.