Now, as of the m10 update, that's a bit easier, and can be made fully automated.
You'll need an existing jumpstart server, probably running Solaris 10, a web server installed and running, and the Tribblix iso image. The following commands should be executed as root.
First, mount up the iso image, on /mnt1 for example
mount -F hsfs`lofiadm -a /path/to/tribblix-0m10.iso` /mnt1
Then go to the mounted image
and run the setup script
./tools/setup-pxe-server -t m10 \
-h /opt/apache2/htdocs/m10 \
There are three arguments here.
The -t flag names the location where the files will be placed on your tftp server, this will be a subdirectory of /tftpboot.
The -h flag tells the script where on the local file system to place the solaris.zlib file and the packages. This must be writable by root.
The -u flag specifies the URL that corresponds to the location you set up with -h.
To add a pxe client, go to the directory under /tftpboot
and there's a script there to set up a pxe client
./add-pxe-client -e 00:14:4f:e5:4d:78 \
You just need to tell it what the ethernet address of your client is. I've also used the -t flag to direct the console onto ttya (this is a convenience shortcut to generate the correct boot arguments). It will configure tftp correctly, and tell you what to add to your dhcp server. (If you're familiar with setting up jumpstart, this is designed to look very similar.)
If you want the system to install itself automatically, then create a configuration file, and tell the script where that file is:
./add-pxe-client -e 00:14:4f:e5:4d:78 \
-t ttya \
The client will be provided with that script as a boot argument. If install configuration is detected, the system will automatically run the normal install script with that configuration file as input.
(If the configuration file isn't valid it'll just exit and leave the system at the login prompt. At this point, if you run the normal installer, it will try and use the configuration file again - so you have the opportunity to fix it [it will be copied into the directory specified by the -h flag to the setup-pxe-server script, so you can edit that directly].)
What can go into this configuration file? Here's an example:
This should be relatively obvious. (It's sourced by the install script, so it's just setting some variables for the install script to use. Yes, it's that straightforward.)
If you want to install to a mirrored root pool, then set ZFSARGS="mirror".
The DRIVELIST specifies which disk or disks to install to.
If BFLAG is set to "-B" then the devices you give will be partitioned with fdisk and given wholly to Tribblix. If you don't set BFLAG, then fdisk won't run and the installer will try and use the devices you specify as it finds them.
You can modify the amount of swap by setting SWAPSIZE.
You can control whether the system automatically reboots at the end of installation or not. By default, the interactive installation doesn't, whereas the automatic installation will reboot.
You can explicitly specify the nodename (not all dhcp servers are configured to hand out the node name, for some reason, or you may wish to specify an unqualified or fully qualified name to override what dhcp gives you).
You can specify the system timezone.
And finally, you can specify one or more overlays to be installed.
That's it, reboot your client and tell it to boot via the network, and off it will go. A few minutes later you'll have an installed system.
The two common failures I've seen are:
- For the initial PXE boot, not getting the URL right, so the system can't boot properly because it can't get hold of /usr
- For automated install, not getting the drive list correct - not helped by the unpredictable way that Solaris enumerates drives. Log in interactively, and run format to see what devices it's actually allocated.
The current implementation is functional and has proven to work pretty well for me, but some improvements are already lined up. There will be a replacement for jumpstart's begin and finish scripts, and a standardized first-boot script mechanism. And you'll be able to use Tribblix itself as the install server, with full integration with a local web and dhcp server (rather than having to set those up separately). Perhaps even a graphical browser UI to manage the server and its clients.
If you're wondering what CARDIGAN stands for, it doesn't, unless it's something like Completely Automated Remote Deployment Including Graphics And Networking. That's what I came up with initially, and the name seemed good enough.