Kernel params

[Licenser]

This pull requests changes the boot script slightly that allows passing all the config parameters as kernel parameters. This makes it possible to boot and install the system via PXE and configure it without manual interaction.

It also adds some additional options for disks, namely all_disks which will use all the disks to install a system which is very helpful for automated installation. In addition it comes with a new profile for disks raid10+2 for a setup with striped mirrors and two spares.

The bootparams.md file explains the parameters used.

[rmustacc]

This is an interesting solution to the problem of automated setup. Though there are also some things that are in it that I know we don't want, ala the automated purge portions based on boot parameters. Another problem is that we have a limited number of boot parameters and so @wesolows has some work in progress to let us pass in additional modules via pxe boot. One of those could be a json file that describe the system configuration. I think that leveraging that, combined with other installer work we have to use the disklayout tools makes a bit more sense. I'd rather see us basically switch to that and optionally override that. this way the behavior you want with respect to RAID 10 would probably be automatic or more changeable. Finally, if we're going to revamp this, we should use shared code across the two.

I'm a bit nervous about duplicating and bifurcating all the setup logic as it means that there will be something additional we have to support and test even though we don't use it. However, we do have an automated way of supplying answers to the prompts in the SDC code that allow us to do that without splitting all the logic into a second duplicate script or taking an alternate path trough the installer. I'll take a look at what it'd require for us to leverage that. When combined with @wesolows boot time modules should make it simpler to get all this passed in.

[xen0l]

Having this merged would be really useful for automated installs. Is there any chance that this will be merged?

[rmustacc]

@xen0l What I described earlier in this is still true. In particular, we still have a limited number of bootparams and more importantly we now actually have boot time modules and a bootfs to display them. We're much more likely to say something where we'll source any file in some part of the /system/boot/ name space rather than trying to stuff more and more into boot params. Or we can use it such that bootfs has something which just answers all of the questions automatically so the machine will be able to automatically answer everything that happens during set up, which is probably the better path here. The reason is that the things which set up does will change over time and so all the things I previously said about how we should do this still stand.

[Licenser]

Something like a 'answers' file would actually be pretty sweet, probably better then he boot parameters in the RP.

I only see one problem, the admin NIC/ip configuration, given that the interface needs to be configured before a answers file could be downloaded from a (say http or tftp) source. However parames for disks, zpool layout, DNS stuff and post boot file could be in a answers file (and probably more if required.

[rmustacc]

@Licenser That's the whole point of the boot time modules that I keep talking about. You can pass in an additional file via pxe that will show up in the file system name space under /system/boot.

[ghost]

More specifically, iPXE (in SDC; you can use any PXE client you like in single-node SmartOS) is responsible for performing an initial configuration of the boot NIC and downloading the boot time modules. The kernel just consumes them as named regions of memory; it does not retrieve them itself nor must the boot NIC and admin NIC be the same physical device or configuration.