From owner-freebsd-stable@FreeBSD.ORG Thu Jun 5 16:31:12 2014 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 ESMTPS id 603F69F for ; Thu, 5 Jun 2014 16:31:12 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7D8E206F for ; Thu, 5 Jun 2014 16:31:11 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward5l.mail.yandex.net (Yandex) with ESMTP id B517DC412B5; Thu, 5 Jun 2014 20:31:00 +0400 (MSK) Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id 61822BE0545; Thu, 5 Jun 2014 20:31:00 +0400 (MSK) Received: from 84.201.164.102-vpn.dhcp.yndx.net (84.201.164.102-vpn.dhcp.yndx.net [84.201.164.102]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id pVwrfKonAl-UxfW2eL9; Thu, 5 Jun 2014 20:30:59 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 769dd565-f6ab-45ec-99e9-5a6519d3866c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1401985859; bh=wOnBN3fehHjoQykCVLnhD0vAX0jl+ySI/yzY5KgNiFY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=oZzRw11AYhzLjMbuFwM48uMBkQiMbchgd278CtS6CGkAXN6wN15pX1CHuT94Gbxyp UewAvqqcKoIiZJxZ2ILpuFnpb1SZsfmlXsYCe5bDywg/1RUhN1ufJkEYCcHgye0wFf cThajZ/0fa//+kIeMt6Jn3lepAk8Jqif3jvAlWjs= Authentication-Results: smtp19.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53909B22.7000801@yandex.ru> Date: Thu, 05 Jun 2014 20:30:26 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Aristedes Maniatis , freebsd-stable Subject: Re: ZFS boot pool selection References: <53902B1D.8030200@ish.com.au> In-Reply-To: <53902B1D.8030200@ish.com.au> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:31:12 -0000 On 05.06.2014 12:32, Aristedes Maniatis wrote: > A. BIOS is able to execute some code placed in a special partition on > a GPT formatted disk. This code is 40kB of hand crafted code and > installed using: > > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 > > The partition itself must be created as > > gpart add -s 222 -a 4k -t freebsd-boot -l boot0 ada0 > > > B. For older BIOS systems without knowledge of GPT, the pmbr is > installed in some other special location on the disk, outside any > partitions. This is 512 bytes of code and does nothing other than > pretend to be MBR to tell the old BIOS (or Windows?) to not mess with > this disk. No. BIOS starts bootcode from PMBR. Then it starts bootcode from freebsd-boot partition. Then it starts loader or kernel. This method also called as legacy boot. UEFI doesn't use bootcode on the freebsd-boot partition. > C. Once gptzfsboot is executing on the CPU, it is able to mount a ZFS > pool in read only mode. Enough to read the kernel and get a full ZFS > implementation in place. gptzfsboot is able to find needed partition and ZFS pool, then it search the zfsloader or kernel and without mounting loads and starts it. http://www.freebsd.org/cgi/man.cgi?gpart#BOOTSTRAPPING > Questions > > 1. If I have two zpools on this machine, how does gptzfsboot know > which one to boot the kernel from? Does it just start by iterating > through all zfs partitions until it finds the zpool metadata cache > which give it enough information to mount some zpool? In other words, > does it pick a random pool from what it can access? AFAIK, it will try to boot from the first ZFS pool that it can find. > 2. How does it know where to find the kernel once it mounts the ZFS > pool, or is the /boot/kernel location hardcoded into the gptzfsboot > code? /boot/kernel/kernel is hardcoded. But when zfsloader is used, it has some environment variables and you are able to change the kernel location. > 3. Once the kernel is booted, then it can read /boot/loader.conf. In > there we can see vfs.root.mountfrom="zfs:tank" but isn't this a bit > late? We've already mounted this pool and loaded the kernel from it. Kernel doesn't read loader.conf. The loader/zfsloader does that. > Can we omit vfs.root.mountfrom entirely? Yes. -- WBR, Andrey V. Elsukov