From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 22:52:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E4A251D for ; Wed, 1 Oct 2014 22:52:13 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id EF03CA74 for ; Wed, 1 Oct 2014 22:52:12 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 8214345087; Wed, 1 Oct 2014 22:44:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 8214345087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1412203442; bh=r1s2ay3tLo2Rbr2HXMmHtgxjsQwZZ2ci3dK0UAexj4k=; h=Date:From:To:Subject:In-Reply-To; b=gjA1fcHBnaxeoOhu384OfwwH3s+tI/4UwAux+V1YUNYQHFm/2MIlyGlh3mzjJoZWY KDh/sElhHZT77LnXuKScbRrfVHO8zfTKGSgHUxxb7OP/F736xUehSNf/Iivqxj4rQP ly8NcmP+V82SMn58nFb4sO/RttNw4xEYnBB3bEG0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 35DFC151DC; Wed, 1 Oct 2014 23:43:58 +0100 (BST) Date: Wed, 1 Oct 2014 23:43:58 +0100 From: Ben Morrow To: karl@denninger.net, freebsd-stable@freebsd.org Subject: Re: Encrypted (GELI) root on ZFS troubles Message-ID: <20141001224356.GA10673@anubis.morrow.me.uk> Mail-Followup-To: karl@denninger.net, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542C71C9.1050907@denninger.net> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:52:13 -0000 Quoth Karl Denninger : > > The problem is that when the system boots geli "finds" the raw device > (in this case /dev/da0p4), prompts for the password and attaches there > instead of in /dev/gpt. Since you're using ZFS, that doesn't matter (as you noticed below). ZFS treats the names that devices were added to the pool with as hints only, and actually searches through all available disks every time it imports a pool, looking for volumes it recognises. > The gpt label is missing --- and equally bad > the "root" pool does not appear to import at boot time either. > > As a result the system tries to mount root from /zboot (even though it's > not been told to, and HAS been told where to mount off the root pool), > but there's no init in there (or anything else other than the boot > filesystem itself) and as a result I get an immediate panic. > > If I boot off a different (working) zfs-based system the probe still > finds the "prompt during boot" flag on that gpt partition and asks for > the password on the device. I can see the pool; zpool import shows it: > > pool: root > id: 17719633931604198170 > state: ONLINE > action: The pool can be imported using its name or numeric identifier. > config: > > root ONLINE > da2p4.eli ONLINE You appear to have exported the pool? I don't think you want to that, since, as you've found, the kernel will not (must not) automatically import pools at boot time. > More-interestingly if I reboot the cloned system with the root pool > imported it does come back up, even though the device is the base > (da2p4.eli) rather than in the /dev/gpt directory. Is there any reason not to simply leave the pool imported when you reboot? The geli device will detach when the system shuts down, after ZFS has finished flushing data; when it reattaches at boot time, ZFS will see an imported pool and make it available. > Anyone know what's going on here? And is there a way to have geli > attach during boot-time off the /dev/gpt directory instead of on the > base device partition name? I don't have a definitive answer to that, but I strongly suspect not. The only place for the information to come from would be /boot/loader.conf, and there's no mention of an appropriate tunable in geli(8). But, as you already found out, it doesn't matter. Ben