From owner-freebsd-embedded@FreeBSD.ORG Sun Sep 16 19:59:48 2012 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2DB41065674 for ; Sun, 16 Sep 2012 19:59:48 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 40E0E8FC12 for ; Sun, 16 Sep 2012 19:59:48 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id q8GJxgC5081788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Sep 2012 21:59:47 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id q8GJxgDg081787 for freebsd-embedded@freebsd.org; Sun, 16 Sep 2012 21:59:42 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sun, 16 Sep 2012 21:59:42 +0200 From: Paul Schenkeveld To: freebsd-embedded@freebsd.org Message-ID: <20120916195942.GA81515@psconsult.nl> References: <20120916211931.31383@relay.ibs.dn.ua> <20120916183340.GA55247@psconsult.nl> <20120916224059.36132@relay.ibs.dn.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120916224059.36132@relay.ibs.dn.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: nanoBSD on GPT gpart-ed media ... X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 19:59:48 -0000 On Sun, Sep 16, 2012 at 10:40:59PM +0300, Zeus Panchenko wrote: > Paul Schenkeveld wrote: > > > > Assuming what you mean is a GPT partition table. > > > yes > > > One of the key features of NanoBSD is that there are two bootable root > > partitions and the boot0 menu is used is case you want to switch back > > to the previous version after an unsuccesful upgrade. > > but is it possible to sacrifice the feature for the sake of the GPT partitioning? > > > > > NanoBSD leaves the fourth slice untouched by default so you can use that > > one for zfs. In fact, I have several machines running exactly like that. > > > > I was unable to use it for zfs :( > may you share the .conf file, please? We have an extensive build infrastructure around (the original) nanobsd.sh script here so sharing my .conf file would only be a small part of the puzzle I'm afraid. In the .conf file I've set NANO_DATASIZE to the amount of space I want to use for ZFS, nanobsd.sh will divide the rest (minus NANO_CONFSIZE) by 2 for the root partitions. When using a recent nanobsd.sh script, you should redefine the populate_data_slice function to do nothing in your .conf file, something like: populate_data_slice ( ) ( # Don't newfs slice 4! ) Because I use this on hard drives too, I use a modified create_i386_diskimage function that only spits out _.disk.image and not _.disk.full (that would end up to be 500GB for my drives). If you tell me what flash, ssd or disk drives you are using, perhaps I can dicrect you a bit further on the easiest way to proceed. With kind regards, Paul Schenkeveld