From owner-freebsd-stable@freebsd.org Sun Nov 8 22:21:49 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 DDDF0A2946E for ; Sun, 8 Nov 2015 22:21:49 +0000 (UTC) (envelope-from t074745734a-e93528f18e950000-8eec6d5ba7584724949b02764469fcf5@bounce.twitter.com) Received: from spring-chicken-ak.twitter.com (spring-chicken-ak.twitter.com [199.16.156.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CAF31186 for ; Sun, 8 Nov 2015 22:21:49 +0000 (UTC) (envelope-from t074745734a-e93528f18e950000-8eec6d5ba7584724949b02764469fcf5@bounce.twitter.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=dkim-201406; t=1447021300; bh=wKGy8y5O+msLIzmN53y1cSh71SwV/NgBLc47t8zJPbE=; h=Date:From:To:Subject:MIME-Version:Content-Type:Message-ID; b=a+rYE5TCkcxXpcpi2eJMvwV7rvVrRNlOkI6YaPjabr1/iP9jO4MxSRCTKp+24B+N2 uOAg9gc24rLowU30L2/MgU3KQ26q9/qGo8EjKNXj213kuF2v7X07YE2LnqQgowCaZG Db9ETwmY5JvuEWrjCCugUSrOWCNbc/mbXIkwNl89b3lPnlvj9YyjJC13HbrwpJSjAN avWG5SfWqSlsmbT5Xc+IMGxhekTJbhM4AKun4hlFQKZYg0Cc2OgNwTyXDzI/5jIU4J 2PMUxV385wQ897xeZ/LjMm6R4LgcooCPLO2g78KV0z2B7GNPTv13toNb5K4hC7shYz VzokBho2gRIJA== X-MSFBL: eyJiIjoiYXRsYS1hcHAtMzEtc3IxLUNvbGQuMTcwIiwidSI6ImZyZWVic2Qtc3Rh YmxlQGZyZWVic2Qub3JnQHVzYiMjMjRAMjQ0QDQxNDQ3OTQ2NzdAMEBmMDNmN2Vk Mjk3YTkxODg0NjBiZDZjZDg1MmFmM2YwYTQ3M2QwMzc4IiwiZyI6IkNvbGQiLCJy IjoiZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcifQ== Date: Sun, 08 Nov 2015 22:21:40 +0000 From: Twitter To: COLLETTE WALFORD Subject: Confirm your Twitter account, COLLETTE WALFORD MIME-Version: 1.0 Feedback-ID: 0040162518f58f41d1f0:16481b2a2bd9895cc9f3f73eb2597daffdce:none:twitterESP Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sun, 08 Nov 2015 22:21:50 -0000 COLLETTE WALFORD, Confirm your email address to complete your Twitter account. It's easy - just click on the button below. Click on the link below or copy and paste it into a browser: https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Faccount%2Fconfirm_user_email%2F4144794677%2F29BCD-FF964-144702%3Ft%3D1%26cn%3DZW1haWxfY29uZmlybV9pbml0%26sig%3D719c749dc34435fe6a3df0fe92d23f25628e5a7b%26al%3D1%26iid%3D8eec6d5ba7584724949b02764469fcf5%26ac%3D1%26autoactions%3D1447021300%26uid%3D4144794677%26nid%3D244%2B308&t=1&cn=ZW1haWxfY29uZmlybV9pbml0&sig=cf308a1adeb336c2a718f0b6577225ae34ff2f29&iid=8eec6d5ba7584724949b02764469fcf5&uid=4144794677&nid=244+308 From owner-freebsd-stable@freebsd.org Mon Nov 9 07:32:47 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 6DEDDA2AA5D for ; Mon, 9 Nov 2015 07:32:47 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CAB01AC8 for ; Mon, 9 Nov 2015 07:32:46 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (pc233031.norma.com [IPv6:fd00::7fa] (may be forged)) by elf.hq.norma.perm.ru (8.14.9/8.14.9) with ESMTP id tA97WJ9q097579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 9 Nov 2015 12:32:30 +0500 (YEKT) (envelope-from emz@norma.perm.ru) From: "Eugene M. Zheganin" Subject: Re: unable to boot a healthy zfs pool: all block copies unavailable To: FreeBSD References: <563BAE37.2090205@norma.perm.ru> <563BD121.4020404@FreeBSD.org> <563C406F.3090003@norma.perm.ru> Message-ID: <56404C03.10600@norma.perm.ru> Date: Mon, 9 Nov 2015 12:32:19 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Mon, 09 Nov 2015 12:32:30 +0500 (YEKT) X-Spam-Status: No hits=-100.2 bayes=0.0000 testhits AWL=0.256,BAYES_00=-1.9, RDNS_NONE=0.793,SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on elf.hq.norma.perm.ru 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: Mon, 09 Nov 2015 07:32:47 -0000 Hi. On 06.11.2015 21:00, Alan Somers wrote: > 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. > You are talking here about gptzfsboot being not smart enough, right ? Since kernel itself is able to find that pool after being booted up from alternative source. So it's a gptzfsboot issue, right ? Eugene.