From owner-freebsd-fs@FreeBSD.ORG Mon Sep 19 08:10:11 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979CE1065674 for ; Mon, 19 Sep 2011 08:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 868FB8FC14 for ; Mon, 19 Sep 2011 08:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8J8ABxx003814 for ; Mon, 19 Sep 2011 08:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8J8AB30003813; Mon, 19 Sep 2011 08:10:11 GMT (envelope-from gnats) Date: Mon, 19 Sep 2011 08:10:11 GMT Message-Id: <201109190810.p8J8AB30003813@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/160706: [zfs] zfs bootloader fails when a non-root vdev exists on a slice before the root slice X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:10:11 -0000 The following reply was made to PR kern/160706; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, peter.maloney@brockmann-consult.de Cc: Subject: Re: kern/160706: [zfs] zfs bootloader fails when a non-root vdev exists on a slice before the root slice Date: Mon, 19 Sep 2011 11:05:53 +0300 I think that this is a WONTFIX bug. It is well know, if less documented, that FreeBSD (gpt)zfsboot boot program tries to use a pool that contains a very first vdev seen by (gpt)zfsboot to load zfsloader or kernel. You just have to take this into account. This behavior makes sense. Trying to boot all pools may create more problems than it solves, e.g. if you have more than one pool that can be booted. You may try to work-around your problem using boot.config file. Place it in a root dataset of a pool that gets used by (gpt)zfsboo (tank, I presume) with the following contents: zroot:/boot/zfsloader P.S. Your example is incomplete, it doesn't show where root1, cache1, log1 come from :-) -- Andriy Gapon