From owner-freebsd-stable@FreeBSD.ORG Sun Sep 15 15:14:12 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 362274FD; Sun, 15 Sep 2013 15:14:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6C5265C; Sun, 15 Sep 2013 15:14:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07263; Sun, 15 Sep 2013 18:14:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VLE1X-0009R4-TQ; Sun, 15 Sep 2013 18:14:07 +0300 Message-ID: <5235CE87.2090607@FreeBSD.org> Date: Sun, 15 Sep 2013 18:13:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <523310E2.4050702@FreeBSD.org> <52331179.4030201@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Sep 2013 15:14:12 -0000 on 15/09/2013 17:16 J David said the following: > Thanks very much for the info Andriy. > > On Fri, Sep 13, 2013 at 9:22 AM, Andriy Gapon wrote: >> Another piece of information is that neither mountpoint nor canmount property >> affects ZFS root mounting. > > It is mountpoint=legacy that boots on this machine and mountpoint=/ > that can't find init, with no other changes. So clearly under some > obscure edge case, this is not strictly correct. I am sure that the same can be said about almost anything documented about any software... > Did your test include zpool root != filesystem root? Because as you > describe one possible cause of the problem is mounting the wrong > filesystem as root, one wonders if somehow with the mountpoint=/ > setting the zpool root (which has no files at all) is incorrectly > being chosen as fsroot with mountpoint=/ on data/root. I.e. perhaps > somewhere in the code is looking for "legacy" (or skipping anything > with a mountpoint set) and defaulting back to the zpool root if it is > not found? I tried to reproduce with exactly the same configuration as you described. To be specific, yes I used data/root as a root filesystem and I set its mountpoint to "/". > Unfortunately there is no way I know of to check and see what the root > filesystem turned out to be after the failure to find init. That > would reduce speculation about what is happening quite a bit. Can the > kernel debugger extract this info? Unfortunately, I am not sure if it is possible to obtain anu useful information from ddb and saving a crash dump is not possible in pre-init environment. I could write a patch that would print some useful debugging info. Will you able to use it? -- Andriy Gapon