`<div dir="ltr">Dan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 10:10 PM, Dan McDonald <span dir="ltr"><<a href="mailto:danmcd@omniti.com" target="_blank">danmcd@omniti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in the middle of rewhacking our PXE installer, Kayak, to ALSO provide support for an ISO-based mildly-interactive installer. Here's the new install menu:<br>
<br>
<br>
Welcome to the OmniOS installation menu<br>
<br>
<br>
1 Find disks, create rpool, and install OmniOS<br>
2 Install OmniOS straight on to a preconfigured rpool<br>
3 Shell (if you need to preconfigure rpool)<br>
4 Terminal type (currently sun-color)<br>
5 Reboot<br>
<br>
<br>
<br>
Basically, #1 will use diskinfo(1M) to list the disks and let you select them. #2 will find an imported and online pool named "rpool" that you configured in advance, and install OmniOS on it. #3 give you a shell to do such configuration.<br>
<br>
I'm somewhat along in this process, but it's VERY rough. I have some of #2's functionality working now.<br>
<br>
If there are brave people who wish to try various stages of the new ISO installer for OmniOS (it will also be the USB one... BSD Loader makes USB construction simple once you have an ISO created), please let me know.<br></blockquote></div><br></div><div class="gmail_extra">Ok, some comments (I'm wearing 2 hats here, one as an omnios<br></div><div class="gmail_extra">customer, the other as someone who's actually written an installer):<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Overall, I think I prefer it to Caiman. But then I was never a<br></div><div class="gmail_extra">fan of Caiman, it was all so slow and klunky. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The ISO is, how can I say this, rather bigger than before.<br><br></div><div class="gmail_extra">Right, so you've dropped the good old solaris.zlib approach<br></div><div class="gmail_extra">and simply gone for a single root archive. I'm thinking of doing<br></div><div class="gmail_extra">the same, by the way, but it has consequences for RAM use and<br></div><div class="gmail_extra">reliability (although hopefully the new loader will handle large boot<br></div><div class="gmail_extra">archives better than grub+bios did).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">It looks like a 64-bit only ISO. (The image you install is dual<br></div><div class="gmail_extra">32/64-bit though.)<br><br></div><div class="gmail_extra">The root archive is uncompressed. You could make the iso smaller<br></div><div class="gmail_extra">by gzipping the root archive.<br><br></div><div class="gmail_extra">The root archive doesn't need the root reserve or anything like as<br></div><div class="gmail_extra">many inodes, which can save you quite a lot of space.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The loader menu on the ISO ought to have a 'boot from disk' option<br></div><div class="gmail_extra">that's removed for the installed system.<br><br></div><div class="gmail_extra">The live media is a bit sparse. There's quite a bit of stuff I would<br></div><div class="gmail_extra">normally expect on a booted system, iostat for starters, that's<br></div><div class="gmail_extra">useful for recovery.<br><br></div><div class="gmail_extra">There are some odd device links under /dev/dsk<br><br></div><div class="gmail_extra">Oddly, diskinfo isn't on the installed system.<br><br></div><div class="gmail_extra">You probably want to be able to control the name of the initial BE<br></div><div class="gmail_extra">you create (think of the case of installing into an older system that<br></div><div class="gmail_extra">already has omnios installed).<br><br></div><div class="gmail_extra">One advantage of the current process is that it copies the currently<br>booted OS onto the installed system. Which (a) copies any manual<br>hacks you've made in order to get it to work, and (b) ensures that<br>the installed system is going to work because it's identical to the one<br>you're running off the media. Having the installed system come from<br></div><div class="gmail_extra">a different source breaks that connection; that may be good or bad<br>depending on your point of view.<br><br></div><div class="gmail_extra">(The live kernel and the installed kernel in this case are different,<br></div><div class="gmail_extra">it just looks like dtrace from a quick look.)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">One nice option would be to have a minimal iso without the kayak<br></div><div class="gmail_extra">dataset, but that allows you to configure minimal networking and<br></div><div class="gmail_extra">then give it a URL to get the archive from. (The use case here is<br></div><div class="gmail_extra">remote mounting the boot iso from my laptop via the server's<br>LOM interface.)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Shoving the kayak dataset into the root archive does make it<br></div><div class="gmail_extra">quite large and increase the memory requirement - but it does<br></div><div class="gmail_extra">allow quite a lot of simplification, as omnios never needs to<br></div><div class="gmail_extra">talk to the media at all, once the loader has read the archive<br>the media can be disposed of.<br><br></div><div class="gmail_extra">That's all for this pass, I think.<br><br></div><div class="gmail_extra">Thanks!<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="m_-6506346005482031353m_-3618266905476952785gmail_signature" data-smartmail="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div>
</div></div></div>
`