Dan, On Mon, Feb 27, 2017 at 10:10 PM, Dan McDonald <dan...@omniti.com> wrote:
> 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: > > > Welcome to the OmniOS installation menu > > > 1 Find disks, create rpool, and install OmniOS > 2 Install OmniOS straight on to a preconfigured rpool > 3 Shell (if you need to preconfigure rpool) > 4 Terminal type (currently sun-color) > 5 Reboot > > > > 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. > > I'm somewhat along in this process, but it's VERY rough. I have some of > #2's functionality working now. > > 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. > 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. Right, so you've dropped the good old solaris.zlib approach 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). It looks like a 64-bit only ISO. (The image you install is dual 32/64-bit though.) The root archive is uncompressed. You could make the iso smaller by gzipping the root archive. 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. 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. There are some odd device links under /dev/dsk Oddly, diskinfo isn't on the installed system. 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). 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. (The live kernel and the installed kernel in this case are different, it just looks like dtrace from a quick look.) 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.) 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. That's all for this pass, I think. Thanks! -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss