From owner-freebsd-questions@FreeBSD.ORG Tue Mar 11 03:30:23 2014 Return-Path: Delivered-To: freebsd-questions@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 00AAA3B2; Tue, 11 Mar 2014 03:30:22 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCAE58DC; Tue, 11 Mar 2014 03:30:22 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id s2B3UEiJ001396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Mar 2014 22:30:14 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Mon, 10 Mar 2014 22:30:13 -0500 From: Sender: Devin Teske To: "'David Christensen'" , References: <53197EF6.4070902@holgerdanske.com> <5319913D.4040207@infracaninophile.co.uk> <10334f5b74b05d9445d071bd08f73a24@dweimer.net> <531A0A0B.3010902@holgerdanske.com> <531D51EF.1080804@holgerdanske.com> <531D6737.4020708@infracaninophile.co.uk> <531E0287.6060907@holgerdanske.com> <1cb801cf3c9a$2c7e7970$857b6c50$@FreeBSD.org> <531E6B85.6030903@holgerdanske.com> In-Reply-To: <531E6B85.6030903@holgerdanske.com> Subject: RE: FreeBSD 10 installer and ZFS root Date: Mon, 10 Mar 2014 20:30:04 -0700 Message-ID: <1ce701cf3cda$32610570$97231050$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQF0C2PIOT0DD3gD1tjGF6Qa8NBRSQKo1RoEAUpEAJABeRIy2QLDDkCEAVpqnP0CUWSQhgEucmDPAbWBLzIBuPx1I5sN1YRQ Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-10_04:2014-03-10,2014-03-10,1970-01-01 signatures=0 Cc: dteske@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 03:30:23 -0000 > -----Original Message----- > From: David Christensen [mailto:dpchrist@holgerdanske.com] > Sent: Monday, March 10, 2014 6:49 PM > To: freebsd-questions@freebsd.org > Subject: Re: FreeBSD 10 installer and ZFS root > > On 03/10/2014 12:51 PM, dteske@FreeBSD.org wrote: > > The installer makes ada0s1a a mirrored vdev so that any disk in the > > pool can be booted from. Imagine what would happen if you had only a > > single boot partition that was not mirrored and you lost that drive? > > Okay. If/ when a second disk is added as a mirror, ZFS will maintain the mirror. > But what about everything else -- partition table, boot manager/ loader(s), > swap, root, whatever? > [Devin Teske] Not talking about adding a mirror. I'm saying that the installer makes a mirror for the bootpool automatically -- spanning all the physical disks in the pool. So it doesn't matter whether you ask the installer to make a stripe, mirror, raidz1, raidz2, or raidz3... you'll *always* end up with a mirrored bootpool that spans all the disks. Let's take a raidz3 of 10 disks for example. Each of the 10 disks is sliced up to provide 3 partitions. The first partition is for the bootpool and is a mirrored vdev type. The second partition is swap. The third partition is the vdev type that you requested (raidz3 in context). This is not to do with adding "a second disk ... as a mirror", however if you did add a disk after the fact, you should take care to consider the following: 1. The disk added should be sliced in the same way so you can add the new disk's first partition as a new block device to the mirror vdev named bootpool. 2. If your zroot is a raidz* vdev, take care not to add a non-redundant vdev to the pool (e.g., add a raidz1 vdev to an existing pool; not a single block device with no parity or backup). > > > And the installer is scriptable. > > Try executing the following command to see how it can be scripted... > > awk '/GLOB/{exit}/CONFIG/,/GLOB/&&/^[A-Z]+=/{print}' \ > > /usr/libexec/bsdinstall/scripts/zfsboot | less > > /usr/libexec/bsdinstall/scripts/zfsboot does not exist on my installation DVD: > > root@p43200:~ # mkdir /media/cdrom > > root@p43200:~ # mount_cd9660 /dev/cd0 /media/cdrom > > root@p43200:~ # ls > /media/cdrom/usr/libexec/bsdinstall/scripts/zfsboot > ls: /media/cdrom/usr/libexec/bsdinstall/scripts/zfsboot: No such file or > directory > > > But /media/cdrom/usr/libexec/bsdinstall/zfsboot does: > > root@p43200:~ # find /media/cdrom/usr/libexec/bsdinstall/ -name > zfsboot > /media/cdrom/usr/libexec/bsdinstall/zfsboot > > root@p43200:~ # less /media/cdrom/usr/libexec/bsdinstall/zfsboot > > > It is clear that zfsboot is one piece in a much larger puzzle. > [Devin Teske] yeah, sorry, I was translating source-code path to installed-path and forgot that it drops the "scripts" directory when installing to libexecdir. > > >> If the installer boot loader creates a RAM disk, copies the installer > >> suite to there, and then lights it off, I might be able to choose Shell > >> early on, edit the right script, and then re-launch the installer. > > Yes, or create a /etc/installerconfig that sets ZFSBOOT_* variables > > before kicking off "bsdinstall zfsboot" (and later the distextract, etc.). > > HINT: If /etc/installerconfig exits with failure status, nothing else is > > performed before reboot (allowing you to control the install 100% by > > calling the various parts to the installation). > > Setting variables in a text file is a possibility. But, not everything > is controlled by a variable. I crawled through zfsboot and found the > spot where the root partition is created for MBR (lines 757-758). > [Devin Teske] What release? Because I'm seeing those 2 lines (757-758) as: 757 758 # That's the same for 11.0-CURRENT, 10.0-STABLE, and 10.0-RELEASE. I didn't check other codelines. > Unfortunately, there is no size variable (gpart uses the rest of the disk). > [Devin Teske] There isn't? The function uses "$bootsize". The function has a description which says the following: 802 f_eval_catch $funcname gpart \ 803 "$GPART_ADD_INDEX_WITH_SIZE" \ 804 1 freebsd-zfs ${bootsize}b ${disk}s1 || 805 return $FAILURE Wherein, searching for "bootpool" reveals at the top of that function... 627 # NOTE: $swapsize and $bootsize should be defined by the calling function. And here's the code that populates "bootsize" from the variable you're expected to set... 906 if ! f_expand_number "$ZFSBOOT_BOOT_POOL_SIZE" bootsize; then If something *isn't* set-able by one of the variables produced by executing the following (reviszed) command... awk '/GLOB/{exit}/CONFIG/,/GLOB/{print}' /usr/libexec/bsdinstall/zfsboot | less Maybe you're running one of the 10.0-BETA or 10.0-RC releases. You should be seeing the following for what you're looking for... 89 # 90 # Default size for boot pool when enabled (e.g., geli(8) or MBR) 91 # 92 : ${ZFSBOOT_BOOT_POOL_SIZE:=2g} -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.