You can monitor the installation of all install clients with the command faimond(8). All clients check if this daemon is running on the install server (or the machine defined by the variable $monserver. Then, a message is sent when a task starts and ends. The fai monitor daemon prints this messages to standard output. There's also a graphical frontend available, called faimond-gui(1).

The install client receives and loads the kernel and initial RAM disk. The kernel boots up and load the RAM disk. It does some hardware detection and then tries to figure where the root file system is located. When booting from network, this is determined by parameters from additional kernel parameters (root=/dev/nfs and nfsroot=/srv/fai/nfsroot). When booting from CD-ROM or USB stick the kernel and initial RAM disk probes removable devices and tries to figure out where the root file system is located. This may also be a compressed file system (using squashfs).

After the root file system is mounted read only, it is made writable by mounting a RAM disk via aufs (another unionfs) on top of it. So it's possible for programms or daemons to write to files inside a read only mounted file system. We are using the package live-initramfs(7) to mount the nfsroot and to make this file system writable using aufs. The package live-initramfs is only needed inside the nfsroot and adds some initramfs hooks.

After the install client has booted, only the script /usr/sbin/fai ^[7] is executed. This is the main script which controls the sequence of tasks for FAI. No other scripts in /etc/init.d/ are executed.

Additional parameters are received from the DHCP daemon and the configuration space is made available via the configured method (an NFS mount by default) from the install server to $FAI. The setup is finished after additional virtual terminals are created and the secure shell daemon for remote access is started on demand.

The variable $FAI_CONFIG_SRC is used to get the FAI configuration space, which is very important, since FAI cannot proceed without the config space.

Now the script fai-class(1) is used to define classes. Therefore several scripts in $FAI/class/ are executed to define classes. All scripts matching [0-9][0-9]* (they start with two digits) are executed in alphabetical order. Every word that these scripts print to the standard output are interpreted as class names. Scripts ending in .source are sourced, so they can define new classes by adding these classes to the variable $newclasses.

The output of these scripts is ignored. These classes are defined for the install client. You can also say this client belongs to these classes. A class is defined or undefined and has no value. Only defined classes are of interest for an install client. The description of all classes can be found in /usr/share/doc/fai-doc/classes_description.txt. It is advisable to document the job a new class performs. Then, this documentation is the base for composing the whole configuration from classes. The scripts 20-hwdetect.source loads kernel modules on demand. The complete description of all these scripts can be found in [cscripts].

After defining the classes, every file matching *.var with a prefix which matches a defined class is executed to define variables. There, you should define the variable $FAI_ACTION and others. By default, $FAI_ACTION is defined via the command fai-chboot(8).

For disk partitioning exactly one disk configuration file from $FAI/disk_config is selected using classes. This file describes how all the local disks will be partitioned, where file systems should be created (and their types like ext2, ext3, reiserfs), and how they are mounted. It's also possible to preserve the disk layout or to preserve the data on certain partitions.

The old tool for partitioning the hard disks is called setup_harddisks. This tool is deprecated. With FAI 3.2.8 the new partitioning tool called setup-storage(8) was added to FAI. It uses parted(8) for editing the partition table and now has support for software RAID and LVM. This tool uses a slightly different format for the configuration files in disk_config than the old tool. Read the manual page for a detailed description of the new format. The variable USE_SETUP_STORAGE now determines which tool to use. When set to 1 it uses the new tool which is now defined in FAIBASE.var by default.

During the installation process all local file systems are mounted relative to /target. For example /target/home will become /home in the new installed system.

When local file systems are created, they are all empty (except for preserved partitions). Now the Debian base system and all requested software packages are installed on the new file systems. First, the base archive is unpacked, then the command install_packages(8) installs all packages using apt-get(8) or aptitude(1) without any manual interaction needed. If a packages requires another package, both commands resolve this dependency by installing the required package.

Classes are also used when selecting the configuration files in $FAI/package_config/ for software installation. The format of the configuration files is described in [packageconfig].

After all requested software packages are installed, the system is nearly ready to go. But not all default configurations of the software packages will meet your site-specific needs. So you can call arbitrary scripts which adjust the system configuration. Therefore scripts which match a class name in $FAI/scripts will be executed. If $FAI/scripts/classname/ is a directory, all scripts that match [0-9][0-9]* in this directory are executed. So it is possible to have several scripts of different types (shell, cfengine, …) to be executed for one class. FAI comes with some examples for these scripts, but you can write your own Bourne, bash, Perl, cfengine or expect scripts.

More information about these scripts are described in [cscripts].

After the customization scripts are executed, FAI will execute some tests if available. Using these test, you can check for errors of the installation or of the softupdate. Test scripts are called via fai-do-scripts(1) and should append it's messages to $LOGDIR/test.log. A Perl module including some useful subroutines can be found in Faitest.pm. A test can also define a new class for executing another tests during next boot via the variable $ADDCLASSES.

When all installation tasks are finished, the log files are written to /var/log/fai/$HOSTNAME/install/ ^[8] on the new system and to the account on the install server if $LOGUSER is defined in fai.conf. It is also possible to specify another host as log saving destination through the variable $LOGSERVER. If $LOGSERVER is not defined, FAI uses the variable $SERVER which is only defined during an initial installation (by get-boot-info). Make sure to set $LOGSERVER in a class/*.var script if you are using the action softupdate.

Additionally, two symlinks will be created to indicated the last directory written to. By default log files will be copied to the log server using scp.

You can use other methods to save logs to the remote server. The currently selected method is defined by the $FAI_LOGPROTO variable in file fai.conf:

All files in the directory /tmp/fai are copied to the FTP server following this example:

At last the system is automatically rebooted if "reboot" was added to $FAI_FLAGS. Normally this should boot the new installed system from its second boot device, the local hard disk. To skip booting from network card, you can use the command fai-chboot(8) to enable localboot.