From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 14:00:21 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7539E1065670 for ; Mon, 9 Jul 2012 14:00:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 942828FC0C for ; Mon, 9 Jul 2012 14:00:20 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q69E0JIA067500; Mon, 9 Jul 2012 16:00:19 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q69E0JjY067499; Mon, 9 Jul 2012 16:00:19 +0200 (CEST) (envelope-from marius) Date: Mon, 9 Jul 2012 16:00:19 +0200 From: Marius Strobl To: Kurt Lidl Message-ID: <20120709140019.GA67276@alchemy.franken.de> References: <20120708025435.GA12487@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120708025435.GA12487@pix.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:00:21 -0000 On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > I built a full 9.0-stable distribution on Friday night, and got to play > with installing it on a spare Netra T1-105 today. Mostly I was > interested in testing out the integrated ZFS boot support that > was commited recently. > > First of all -- it works! Thanks very much to all who made it possible! > > After working through a couple of nits in my script that installs it all, > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > The zfsboot bootblock's warning about not being able to open non-existant > devices are pretty extranous, but other than that, it seems to function OK. That's more or less a cosmetic problem for now; there's no standard Open Firmware method allowing to test whether the device corresponding to a (automatically) created device alias actually exists short of trying to open it, with OFW causing at least the "Drive not ready" part on its own. There are some Sun specific extensions to the default methods whose names sound like they could be of some help here. I haven't gotten around to actually test whether this is the case or whether they actually exist in all OFW implementations of all sun4u models. If the aliases were artificially created via the `nvalias` command ("disk9" sounds a bit unusual for the automatically created ones) you can get rid of the none existing ones via `nvunalias` (needs a `reset-all` or power-cycle to take effect). > > The other thing that seems wrong is the 'bootpath="zfs:zroot:"' > output -- notice the trailing ":" in the output, that's not there in > the /boot/loader.conf file. I'm not really sure about this one; actually that's the bootpath created and internally used by the machine independent ZFS boot bits. I've never seen an x86 machine booting from ZFS so maybe it's just omitted there. > And finally, the device attachment messages for da0 and cd0 seem to > have gotten interspersed in the output on the kernel. A little confusing, > but not the end of the world. That still is an architecture independent problem with the console output, even with PRINTF_BUFR_SIZE=128 ... Marius