Note: Sun has in its PROM the ability to do a ``boot net'' which in fact uses rarp and tftp for getting the IP address of the station, the IP address of a gateway and subsequently a standalone program which will bring the machine on the net. We could not use this facility as is because rarp works only on a subnet (see 1.2.2) and necessitates the maintenance of lists of machines with their ethernet to IP address translation (see 1.2.5). To make up for these shortcomings we asked Sun to create the standalone program on a floppy.
In the first step the station comes up by reading a standalone program residing on a floppy. The standalone program is called CNBoot and was written by Sun following our request and specification. CNBoot asks the installer 3 questions: the IP address of the machine to install, the IP address of a gateway and the IP address of the install server. The third piece of information defaults to the address of one of the two install servers we use. The whole typing takes few seconds. (see 1.1.1).
The machine to be installed will proceed from now on to pretend to be a Diskless Sun station. It uses the MINIROOT on the install server and the bootparam file on the install server. Unfortunately the Diskless Sun paradigm involves running the rarp and bootparam protocols which where in conflict with requirements (1.2.2, 1.2.1 and 1.2.5). To subvert this , Sun delivered to us a module, nfs_dlboot, which has to be installed on the MINIROOT kernel. This module has to be updated from release to release and we relay on Sun for getting us the new hacked nfs_dlboot, each time we have a new Solaris release.
Once the MINIROOT is booted, the floppy is ejected, 5 minutes after starting the installation process (see 1.1.2).
When the machine reaches multi-user mode, it starts executing the phase2.sh script, on the MINIROOT. The script asks first if you want to do a standard or custom installation. If you answer that you want to make a custom installation it asks you which rev you want to install.Then the script partitions the hard disk,according to some specifications which are found on some MINIROOT files. For each disk type we support we have another partition directive on the MINIROOT. We do not allow for flexible partitioning at this time. Initially the economy in typing (1.1.1) and how fast you could walk away from the station (1.1.2) where the most important considerations. The lack of flexibility is a drawback for the operators (1.2.7). Once the disk is partitioned and newfs is run, phase2.sh mounts AFS using for cache the disk partition which is going to be the future AFS cache.
With AFS mounted and the disk primed, phase2.sh invokes a script residing in AFS: phase3.sh. In less than 45 minutes (1.1.3), phase3 script tracks or copies all the files necessary from the MASTER IMAGE. The MASTER IMAGE is a Sun OS image of an workstation, which we keep in AFS (under /afs/athena/system/``release''/os and /afs/athena/system/``release''/srvd).
At this time we do not deal in any way with possible failures, due to the network, in the track and copy phase (1.1.4).
Once all files are copied, tracked and initialized, we reboot the machine. The whole process may take less than 45 minutes (1.1.3).