[OmniOS-discuss] CALL FOR VOLUNTEERS - Kayak for ISO alpha

[Dan McDonald]

> On Feb 28, 2017, at 5:22 PM, Peter Tribble <peter.tribble at gmail.com> wrote:
> 
> Dan,

<SNIP!>

> Ok, some comments (I'm wearing 2 hats here, one as an omnios
> customer, the other as someone who's actually written an installer):
> 
> Overall, I think I prefer it to Caiman. But then I was never a
> fan of Caiman, it was all so slow and klunky. 
> 
> The ISO is, how can I say this, rather bigger than before.

Yes.  This is because I wanted to get it running first.

I will note that if I used 7z instead of bzip2, I can shrink the ZFS image that lives in the ISO.

> Right, so you've dropped the good old solaris.zlib approach

Oddly enough, solaris.zlib uses 7z, IIRC.

> and simply gone for a single root archive. I'm thinking of doing
> the same, by the way, but it has consequences for RAM use and
> reliability (although hopefully the new loader will handle large boot
> archives better than grub+bios did).

Loader makes a lot of things better.

> It looks like a 64-bit only ISO. (The image you install is dual
> 32/64-bit though.)

OmniOS officially only supports 64-bit installs.  That we still provide a 32-bit one is an artifact of limited resources, not a statement of direction.

> The root archive is uncompressed. You could make the iso smaller
> by gzipping the root archive.

Can boot_archive be compressed?  I didn't think it could.

> The root archive doesn't need the root reserve or anything like as
> many inodes, which can save you quite a lot of space.
> 
> The loader menu on the ISO ought to have a 'boot from disk' option
> that's removed for the installed system.

Interesting idea.  I'll make note of that.

> The live media is a bit sparse. There's quite a bit of stuff I would
> normally expect on a booted system, iostat for starters, that's
> useful for recovery.

Note the provenance of this code.  It comes from the kayak PXE booter.  Basically, I've been adding more to what the PXE booter sends to be complete in the ISO.

> There are some odd device links under /dev/dsk
> 
> Oddly, diskinfo isn't on the installed system.

Oh, on the INSTALLED system.  Yeah, that's a bug, and can be fixed in github.com:/omniti-labs/kayak.

> You probably want to be able to control the name of the initial BE
> you create (think of the case of installing into an older system that
> already has omnios installed).

Currently no installer does this.  I don't want to go down the path of feeping-creaturism unless it's a huge win.  One user != huge.

> One advantage of the current process is that it copies the currently
> booted OS onto the installed system. Which (a) copies any manual
> hacks you've made in order to get it to work, and (b) ensures that
> the installed system is going to work because it's identical to the one
> you're running off the media. Having the installed system come from
> a different source breaks that connection; that may be good or bad
> depending on your point of view.

That's technically wrong. In practice they do come from the same source bits, but the .zfs.bz2 file COULD be generated elsewhere.

> (The live kernel and the installed kernel in this case are different,
> it just looks like dtrace from a quick look.)

For now that's mostly true.

> One nice option would be to have a minimal iso without the kayak
> dataset, but that allows you to configure minimal networking and
> then give it a URL to get the archive from. (The use case here is
> remote mounting the boot iso from my laptop via the server's
> LOM interface.)

This is how kayak for PXE works now.  It wouldn't be hard to not include the .zfs.bz2 and instead include a URL, and a network-bringup script.  Said script would need instant-naming capability (i.e. DNS) along with DHCP configuration.  Kayak for PXE grabs all of this from the DHCP server today.

> Shoving the kayak dataset into the root archive does make it
> quite large and increase the memory requirement - but it does
> allow quite a lot of simplification, as omnios never needs to
> talk to the media at all, once the loader has read the archive
> the media can be disposed of.

Ideally yes.

> That's all for this pass, I think.

Your quick-networking idea is something I've been considering in a different context --> full DHCP-node install.  Basically, the media runs, guesses disks and interfaces, slaps bits, tells new bits to DHCP and DNS, and it's one-button install.  Again, I want to beware of feeping-creaturism, though.

Thank you!
Dan