zfs booting feedback

[Marius Strobl]

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