Date: Sun, 08 Nov 2015 22:21:40 +0000 From: Twitter <verify@twitter.com> To: COLLETTE WALFORD <freebsd-stable@freebsd.org> Subject: Confirm your Twitter account, COLLETTE WALFORD Message-ID: <DE.DF.36078.4FACF365@twitter.com>
next in thread | raw e-mail | index | archive | help
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: <owner-freebsd-stable@freebsd.org> 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 <freebsd-stable@mailman.ysv.freebsd.org>; 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 <freebsd-stable@freebsd.org>; 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 <freebsd-stable@freebsd.org>; Mon, 9 Nov 2015 12:32:30 +0500 (YEKT) (envelope-from emz@norma.perm.ru) From: "Eugene M. Zheganin" <emz@norma.perm.ru> Subject: Re: unable to boot a healthy zfs pool: all block copies unavailable To: FreeBSD <freebsd-stable@freebsd.org> References: <563BAE37.2090205@norma.perm.ru> <563BD121.4020404@FreeBSD.org> <563C406F.3090003@norma.perm.ru> <CAOtMX2gB_-pygSRGtaHK+tEHHJsAxSx4uce4Di5uAwaPbwH8KQ@mail.gmail.com> 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: <CAOtMX2gB_-pygSRGtaHK+tEHHJsAxSx4uce4Di5uAwaPbwH8KQ@mail.gmail.com> 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 <freebsd-stable.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>; List-Post: <mailto:freebsd-stable@freebsd.org> List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE.DF.36078.4FACF365>