[OmniOS-discuss] Improved, but still alpha, ISO installer

Dan McDonald danmcd at omniti.com
Fri Mar 3 15:23:57 UTC 2017


> On Mar 3, 2017, at 10:06 AM, Peter Tribble <peter.tribble at gmail.com> wrote:
> 
> Dan,
> 
> On Thu, Mar 2, 2017 at 2:40 AM, Dan McDonald <danmcd at omniti.com> wrote:
> Please refresh your copy by downloading here:
> 
>         http://kebe.com/~danmcd/webrevs/r151021-kayak.iso
> 
> So I had a play with this on vultr (cloud, KVM based, virtio)
> 
> And it worked pretty well, takes a while to load the boot archive but
> other than that worked just fine.

The boot archive takes so long because I was lazy and put the ZFS send stream IN the boot archive itself, instead of figuring out how to make it a separate mount point from boot archive and have it be on the ISO, but not on the boot archive.

> Couple of things I noticed:
> 
> There's no org.opensolaris.libbe:uuid property set on the root filesystem's
> dataset, which I think you'll need

Even after "beadm activate"?  That seems odd.

OTOH, I've not noticed this getting set in either traditional Kayak (the PXE one) OR even the caiman installer we use.  I wonder if that property is set after a fresh old-school Installation?  (I can find out later...)

> I saw a message at boot I didn't recognise:
> "Short hash module of length 0x0 bytes; ignoring"

This is a known bug.  We're missing the digest(1M) command & friends in the image the installer uses for rootfs.  I need to add this, that way bootadm(1M) will DTRT.  If that brings along too much code, the gnu-binutils sha1sum is already there, so I can create these by hand during the installer script.

> Mind you, it's confused between c3t0d0 and c2t0d0:
> 
> $ zpool status
>   pool: rpool
>  state: ONLINE
>   scan: scrub repaired 0 in 0h0m with 0 errors on Fri Mar  3 15:03:09 2017
> config:
> 
>     NAME        STATE     READ WRITE CKSUM
>     rpool       ONLINE       0     0     0
>       c3t0d0    ONLINE       0     0     0
> 
> # format
> Searching for disks...done
> 
> 
> AVAILABLE DISK SELECTIONS:
>        0. c2t0d0 <Virtio-Block Device-0000-40.00GB>
>           /pci at 0,0/pci1af4,2 at 4/blkdev at 0,0
> 
> It was c3t0d0 in the installer shell, but that device no longer exisst and it's
> moved to c2t0d0.

What does "diskinfo" say?  Also, I seem to recall there's an issue with Xen-like environments where the same disk gets two /dev/ entries.

Thank you!
Dan



More information about the OmniOS-discuss mailing list