From owner-freebsd-stable@freebsd.org Fri Nov 6 16:00:05 2015 Return-Path: Delivered-To: freebsd-stable@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 EEF84A27CC8 for ; Fri, 6 Nov 2015 16:00:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B638C1A23 for ; Fri, 6 Nov 2015 16:00:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by oiww189 with SMTP id w189so44107895oiw.3 for ; Fri, 06 Nov 2015 08:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d3Qx1x8QFh06xAJKqmWSIDUSqGh3FOH4ITmaaNwh7wA=; b=hJDQfjnY10GRa5Vax4l0bhBhX8pn8jQphZkewdtSVi4DU5sk5LTLDPyQN/dyv/cz88 VhkH35ntnMVzAPtBtGSK10kTBD9PPQ3g48KClrlp4QkQ0dWZeMCJkN1yuNJXU1VM72+7 OmHFk8ssiPb95fFa3WWP/T2RKNn0TERIgxEgklchcJf3+lROKVfL+QGC2FGbHlQWyfii 4e5r7yogmzA1pY9+050Rpu9uxr9IL7tQaHyUrAng8ne1smA7gcU9tUwEhwAYZwrSFWLY vBPofErXmzYR4YJVgz8qzbzs91RY+mN8JEWCE1nkbJ3NhKnlLjCi5Z3HCak++WH7+2Vk DqfQ== MIME-Version: 1.0 X-Received: by 10.202.212.68 with SMTP id l65mr1331404oig.54.1446825604130; Fri, 06 Nov 2015 08:00:04 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.1.206 with HTTP; Fri, 6 Nov 2015 08:00:04 -0800 (PST) In-Reply-To: <563C406F.3090003@norma.perm.ru> References: <563BAE37.2090205@norma.perm.ru> <563BD121.4020404@FreeBSD.org> <563C406F.3090003@norma.perm.ru> Date: Fri, 6 Nov 2015 09:00:04 -0700 X-Google-Sender-Auth: _fgib-Umi5_Snplv2IKoX2US_yc Message-ID: Subject: Re: unable to boot a healthy zfs pool: all block copies unavailable From: Alan Somers To: "Eugene M. Zheganin" Cc: FreeBSD Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 16:00:05 -0000 On Thu, Nov 5, 2015 at 10:53 PM, Eugene M. Zheganin wrote: > Hi. > > On 06.11.2015 02:58, Andriy Gapon wrote: >> >> It could be that your BIOS is not able to read past 1TB (512 * INT_MAX). That >> seems to be a rather common problem for consumer motherboards. >> Here is an example of how it looked for me: >> https://people.freebsd.org/~avg/IMAG1099.jpg >> Fortunately, it wasn't a root pool that got the error. > Mine looks way different: yours shows the pool info, mine shows 'BTX > halted' message: http://zhegan.in/files/cannot-read-MOS.jpg . I'm > running the latest BIOS for this motherboard (Gigabyte Z77P-D3, updated > yesterday, stilll it's only 2012h year). If it's still the BIOS-related > bug, what wokraround can I use - reslice the disk and create the root > pool inside first Tb, right ? > > Thanks. > Eugene. I notice that my 10.2-RELEASE VM prints the same message about "all block copies unavailable" and then continues to boot just fine. So I wonder if that part is just red herring. There is another possibility here: I have seen a bug where ZFS attempts to open the root pool's vdevs by path (eg ada0p3) but can't find them because disks have been replaced and no longer have their old devnames. So vdev_geom searches through the list of geom providers looking for any provider with the correct ZFS GUID. Normally it would find the right devname (eg ada1p3). But sometimes, because the disks are partitioned, it will find the wrong partition first (eg ada1). Since ZFS has labels at both the beginning and the end of each vdev, vdev_geom will see the label at the end of ada1 (really, it's the label at the end of ada1p3, but it shares the same LBA that a label at the end of ada1 would) and think that it opened ada1 successfully. vdev_geom_open will then return, and at some later date another part of ZFS will fail to read the MOS, and your boot will fail. If this is the case, then there are three possible solutions: 1) Fix vdev_geom. I'm currently testing a patch to do just that. 2) With power off, shuffle disks around until the boot disks have the same devnames that they had the last time you successfully booted. If this is a SATA-only computer, swapping cables between different mobo ports should be enough. 3) Boot from your USB stick and carefully (oh so carefully!) erase the ZFS labels at the end of the boot disk. Don't touch the labels at the beginning. If your boot pool is mirrored, it should be sufficient to erase the labels on one disk only. -Alan