Now read this manual, then enjoy the fully automatic installation and your saved time.

Have you ever performed identical installations of an operating system several times? Would you like to be able to install a Linux cluster with dozens of nodes single handedly?

Repeating the same task again and again is boring — and will surely lead to errors. Also a whole lot of time could be saved if the installations were done automatically. An installation process with manual interaction does not scale. But clusters have the habit of growing over the years. Think long-term rather than planning just a few months into the future.

In 1999, I had to perform an installation of a Linux cluster with one server and 16 clients. Since I had much experience doing automatic installations of Solaris operating systems on SUN SPARC hardware, the idea to build an automatic installation for Debian was born. Solaris has an automatic installation feature called JumpStart ^[1]. In conjunction with the auto-install scripts from Casper Dik ^[2], I could save a lot of time not only for every new SUN computer, but also for re-installation of existing workstations. For example, I had to build a temporary LAN with four SUN workstations for a conference, which lasted only a few days. I took these workstations out of our normal research network and set up a new installation for the conference. When it was over, I simply integrated the workstations back into the research network, rebooted just once, and after half an hour, everything was up and running as before. The configuration of all workstations was exactly the same as before the conference, because everything was performed by the same installation process. I also used the automatic installation for reinstalling a workstation after a damaged hard disk had been replaced. It took two weeks until I received the new hard disk but only a few minutes after the new disk was installed, the workstation was running as before. And this is why I chose to adapt this technique to a PC cluster running Linux.

FAI is a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large infrastructures and clusters. You can take one or more virgin PCs, turn on the power and after a few minutes Linux is installed, configured and running on the whole cluster, without any interaction necessary. Thus, it’s a scalable method for installing and updating a cluster unattended with little effort involved. FAI uses the Debian GNU/Linux distribution and a collection of shell and Perl scripts for the installation process. Changes to the configuration files of the operating system can be made by cfengine, shell, Perl and expect scripts.

FAI’s target group are system administrators who have to install Linux onto one or even hundreds of computers. Because it’s a general purpose installation tool, it can be used for installing a Beowulf cluster, a rendering farm or a Linux laboratory or a classroom. Also large-scale Linux networks with different hardware or different installation requirements are easy to establish using FAI. But don’t forget to plan your installation. Chapter [plan] has some useful hints for this topic.

First, some terms used in this manual are described.

The install client which will be installed using FAI, is booted via network card or from CD or USB stick. It gets an IP address and boots a Linux kernel which mounts its root file system via NFS from the install server. After the kernel is loaded, the FAI startup script performs the automatic installation which doesn’t need any interaction. First, the hard disks will be partitioned, file systems are created and then software packages are installed. After that, the new installed operating system is configured to your local needs using some scripts. Finally the new operating system will be booted from the local disk.

The details of how to install the computer (the configuration) are stored in the configuration space on the install server. Configuration files are shared among groups of computers if they are similar using the class concept. So you need not create a configuration for every new host. Hence, FAI is a scalable method to install a big cluster with a great number of nodes.

FAI can also be used as a network rescue system. You can boot your computer, but it will not perform an installation. Instead it will run a fully functional Debian GNU/Linux without using the local hard disks. Then you can do a remote login and backup or restore a disk partition, check a file system, inspect the hardware or do any other task.

The following items are required for an installation via FAI.

The NFS server will be enabled automatically when installing the fai-server package.

The script mkdebmirror ^[4] can be used for creating your own local Debian mirror. This script uses the script debmirror(1). A partial Debian mirror only for i386 architecture for Debian 5.0 (aka lenny) without the source packages needs about 22GB of disk space. Accessing the mirror via HTTP will be the default way in most cases. To see more output from the script call mkdebmirror -v. A root account is not necessary to create and maintain the Debian mirror.

You can use the command fai-mirror(1) for creating a partial mirror that only contains the software packages that are used in the classes in your configuration space. A partial mirror containing all package for the simple examples from the package fai-doc will only need about 440MB of disk space.

To use HTTP access to the local Debian mirror, install a web server and create a symlink to the local directory where your mirror is located:

faiserver# apt-get install apache2
faiserver# ln -s /files/scratch/debmirror /var/www/debmirror

Create a file sources.list(5) in /etc/fai/apt which gives access to your Debian mirror. An example can be found in /usr/share/doc/fai-doc/examples/etc. Also add the IP-address of the HTTP server to the variable $NFSROOT_ETC_HOSTS in make-fai-nfsroot.conf when the install clients have no DNS access.

To set up a FAI install server you need at least the packages fai-server and fai-doc. The package fai-quickstart contains dependencies on all required packages for an install server. Do not install the package fai-nfsroot on a normal system. This package can only be installed inside the nfsroot.

If you would like to install all packages that are useful for a FAI install server, use the following command

# aptitude install fai-quickstart
Reading Package Lists... Done
Building Dependency Tree
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done

The following NEW packages will be installed:
  apt-move{a} isc-dhcp-server{a} fai-doc{a} fai-quickstart fai-server{a}
  genisoimage{a} inetutils-inetd{a} nfs-kernel-server{a}
  openssh-server{a} syslinux-common{a} tftpd-hpa{a}
0 packages upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 2593kB of archives. After unpacking 8561kB will be used.
Do you want to continue? [Y/n/?]

The configuration for the FAI package (not the configuration data for the install clients) is defined in fai.conf. Definitions that are only used for creating the nfsroot are located in make-fai-nfsroot.conf. Edit these files before calling fai-setup. These are important variables in make-fai-nfsroot.conf:

These are important variables in fai.conf:

If $FAI_CONFIG_SRC is undefined in fai.conf, then the default is to use an NFS mount from the FAI install server onto the install client. It’s the same as nfs://hostname/$FAI_CONFIGDIR with the host name determined on the install server. Remember that this directory must be exported to all install clients, so that all files can be read by root.

A list of variables used by FAI can be found at http://wiki.fai-project.org/wiki/Variables.

The content of /etc/fai/apt/sources.list and $FAI_DEBMIRROR are used by the install server and also by the clients. If your install server has multiple network cards and different host names for each card (as for a Beowulf server), use the install server name which is known by the install clients.

FAI uses debootstrap(8) and apt-get(8) to create the nfsroot file system in /srv/fai/nfsroot. It needs about 380MB of free disk space. After editing fai.conf and make-fai-nfsroot.conf call fai-setup.

faiserver[~]# fai-setup -v
Using configuration files from /etc/fai
Creating FAI nfsroot in /srv/fai/nfsroot/live/filesystem.dir.
By default it needs more than 380 MBytes disk space.
This may take a long time.
Creating base system using debootstrap version 1.0.10lenny1
Calling debootstrap lenny /srv/fai/nfsroot/live/filesystem.dir http://cdn.debian.net/debian
.
Creating base.tgz
.
Upgrading /srv/fai/nfsroot/live/filesystem.dir
.
nfs-common fai-nfsroot module-init-tools ssh rdate lshw portmap rsync lftp less dump reiserfsprogs e2fsprogs usbutils hwinfo psmisc pciutils hdparm smartmontools parted mdadm lvm2 dnsutils ntpdate dosfstools jove xfsprogs xfsdump procinfo dialog discover console-tools console-common iproute udev subversion liblinux-lvm-perl cfengine2 libapt-pkg-perl grub lilo read-edid linux-image-486
install_packages: reading config files from directory /etc/fai
install_packages: read config file NFSROOT
.
.
`/etc/fai/NFSROOT' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/NFSROOT'
`/etc/fai/apt' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/apt'
`/etc/fai/apt/sources.list' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/apt/sources.list'
`/etc/fai/fai.conf' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/fai.conf'
`/etc/fai/live.conf' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/live.conf'
`/etc/fai/make-fai-nfsroot.conf' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/make-fai-nfsroot.conf'
`/etc/fai/menu.lst' -> `/srv/fai/nfsroot/live/filesystem.dir/etc/fai/menu.lst'
Shadow passwords are now on.
Removing `local diversion of /usr/sbin/update-initramfs to /usr/sbin/update-initramfs.distrib'
update-initramfs: Generating /boot/initrd.img-2.6.26-2-486
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays.
W: mdadm: failed to auto-generate temporary mdadm.conf file.
W: mdadm: no configuration file available.
`/srv/fai/nfsroot/live/filesystem.dir/boot/vmlinuz-2.6.26-2-486' -> `/srv/tftp/fai/vmlinuz-2.6.26-2-486'
`/srv/fai/nfsroot/live/filesystem.dir/boot/initrd.img-2.6.26-2-486' -> `/srv/tftp/fai/initrd.img-2.6.26-2-486'
DHCP environment prepared. If you want to use it, you have to enable the dhcpd and the tftp-hpa daemon.
Removing `local diversion of /sbin/discover-modprobe to /sbin/discover-modprobe.distrib'
make-fai-nfsroot finished properly.    <=== *
No diversion `any diversion of /sbin/discover-modprobe', none removed
Log file written to /var/log/fai/make-fai-nfsroot.log
Re-exporting directories for NFS kernel daemon....

   You have no FAI configuration space yet. Copy the simple examples with:
   cp -a /usr/share/doc/fai-doc/examples/simple/* /srv/fai/config
   Then change the configuration files to meet your local needs.
Please don't forget to fill out the FAI questionnaire after you've finished your project with FAI.

FAI setup finished.                    <=== *
Log file written to /var/log/fai/fai-setup.log

A complete example of fai-setup.log is available on the FAI web page. It’s important that you find both lines that are marked with an asterisk in your output. Otherwise something went wrong. If you’ll get a lot of blank lines, it’s likely that you are using konsole, the X terminal emulation for KDE which has a bug. Try again using xterm.

The warning messages from dpkg about dependency problems can be ignored. If you have problems running fai-setup, they usually stem from make-fai-nfsroot(8). Adding -v gives you a more verbose output which may help you pinpoint the error. The output is written to /var/log/fai/make-fai-nfsroot.log. It may help to enter the chroot environment manually using this command.

faiserver# chroot /srv/fai/nfsroot/live/filesystem.dir

The setup routine adds some lines to /etc/exports to export the nfsroot and the configuration space to all hosts that belong to the netgroup faiclients. If you already export a parent directory of these directories, you may comment out these lines, since the kernel NFS server has problems exporting a directory and one of its subdirectories with different options.

All install clients must belong to this netgroup, in order to mount these directories successfully. Netgroups are defined in the file /etc/netgroup or in the corresponding NIS map. An example can be found in /usr/share/doc/fai-doc/examples/etc/netgroup. For more information, read the manual pages netgroup(5) and the NIS HOWTO. After changing the netgroups, the NFS server has to reload its configuration. Use the following command:

faiserver# /etc/init.d/nfs-kernel-server reload

The setup also creates the account fai (defined by $LOGUSER) if not already available. So you can add a user before calling fai-setup(8) using the command adduser(8) and use this as your local account for saving log files. The log files of all install clients are saved to the home directory of this account. If you boot from network card, you should change the primary group of this account, so this account has write permissions to /srv/tftp/fai in order to change the symbolic links to the kernel image which is booted by a client.

After that, FAI is installed successfully on your server, but has no configuration for the install clients. Start with the examples from /usr/share/doc/fai-doc/examples/simple/ using the copy command above and read [config]. Before you can set up a DHCP daemon, you should collect some network information of all your install clients. This is described in section [mac].

When you make changes to fai.conf, make-fai-nfsroot.conf the nfsroot has to be rebuilt by calling make-fai-nfsroot(8). If you only like to install a new kernel to the nfsroot add the flags -k or -K to make-fai-nfsroot. This will not recreate your nfsroot, but only updates your kernel and kernel modules inside the nfsroot or add additional packages into the nfsroot.

The setup of FAI adds the fai account, exports file systems and calls make-fai-nfsroot(8). If you call make-fai-nfsroot -v you will see more messages. When using a local Debian mirror, it’s important that the install server can mount this directory via NFS. If this mount fails, check /etc/exports and /etc/netgroup.

Almost all modern bootable network cards support the PXE boot environment. Some network cards (e.g. on notebooks) have a fixed boot configuration, so they can only use the PXE boot protocol. This requires a PXE Linux boot loader and a special version of the TFTP daemon, which is available in the Debian package tftpd-hpa.

First, install following additional needed packages:

faiserver# apt-get install isc-dhcp-server syslinux-common tftpd-hpa

Then set up the DHCP daemon. A sample configuration file can be found in /usr/share/doc/fai-doc/examples/etc/dhcpd.conf. Copy this file to /etc/dhcp/dhcpd.conf.

The install client then loads the pxelinux boot loader which receives its configuration via TFTP from a file in the directory /srv/tftp/fai/pxelinux.cfg (defined by the variable $TFTPROOT in make-fai-nfsroot.conf). Using the command fai-chboot(8) you can define which kernel will be loaded by the PXE Linux loader and which additional parameters are passed to this kernel. You should read the manual pages, which give you some good examples.

See /usr/share/doc/syslinux/pxelinux.doc for more detailed information.

If your network card can’t boot by itself, you can create a small boot floppy that uses etherboot, which will provide the PXE feature for your network card. So you can use DHCP and TFTP to get the install kernel that was created with mknbi-linux(8). A lot of ethernet cards support booting via ethernet if a special boot EPROM is inserted or booted from floppy provided by http://rom-o-matic.net. In depth documentation about booting via Ethernet may be found at http://www.etherboot.org.

It’s possible to perform an automatic installation from CD-ROM without an install server. The CD-ROM contains all data needed for the installation. The command fai-cd(8) puts the nfsroot, the configuration space and a subset of the Debian mirror onto a CD-ROM. The partial mirror is created using the command fai-mirror(1) which contains all packages that are used by the classes used in your configuration space. A sample ISO image is available at http://fai-project.org/fai-cd.

Using the command fai-cd(8) you can also create a bootable USB stick. First, format your stick with an ext2 file system (ext3 makes no sense on flash memory devices). Then mount it. After that call:

faiserver# fai-cd -m /path/to/mirror -u /path/to/mounted/stick

Then unmount the USB stick. The USB stick must be formatted with an ext2 file system. VFAT is not yet supported. Currently the file system that will be written onto the stick is not compressed.

Now it’s time to boot your install clients for the first time. They will fail to boot completely, because no BOOTP or DHCP daemon is running yet or recognizes the hosts. But you can use this first boot attempt to easily collect all Ethernet addresses of the network cards.

You have to collect all Ethernet (MAC) addresses of the install clients and assign a host name and IP address to each client. To collect all MAC addresses, now boot all your install clients. While the install clients are booting, they send broadcast packets to the LAN. You can log the MAC addresses of these hosts by running the following command simultaneously on the server:

faiserver# tcpdump -qtel broadcast and port bootpc >/tmp/mac.list

After the hosts have been sent some broadcast packets (they will fail to boot because bootpd isn’t running or does not recognize the MAC address yet) abort tcpdump by typing ctrl-c. You get a list of all unique MAC addresses with these commands:

faiserver$ perl -ane 'print "\U$F[0]\n"' /tmp/mac.list|sort|uniq

After that, you only have to assign these MAC addresses to host names and IP addresses (/etc/ethers and /etc/hosts or corresponding NIS maps). With this information you can configure your DHCP daemon (see the section [bootdhcp]). I recommend to write the MAC addresses (last three bytes will suffice if you have network cards from the same vendor) and the host name in the front of each chassis.

An example for dhcpd.conf(5) is available in /usr/share/doc/fai-doc/examples/etc/dhcpd.conf, which is working with version 3.x of the DHCP daemon. Start using this example and look at all options used therein. The only FAI specific information inside this configuration file is to set filename to fai/pxelinux.0 and to set next-server and server-name. All other information is only network related data, which is used in almost all DHCP configurations.

If you make any changes to the DHCP daemon configuration, you must restart the daemon.

# /etc/init.d/isc-dhcp-server restart

By default, the DHCP daemon writes its log files to /var/log/daemon.log. The command fai-chboot(8) is used for creating a per host configuration for the pxelinux environment.

When booting from network card with PXE you will see:

Managed PC Boot Agent (MBA) v4.00
.
.
Pre-boot eXecution Environment (PXE) v2.00
.
.
DHCP MAC ADDR: 00 04 75 74 6E 4A
DHCP.../
CLIENT IP: 192.168.1.12 MASK: 255.255.255.0  DHCP IP: 192.168.1.250
GATEWAY IP: 192.168.1.254

PXELINUX 3.71 (Debian-2008-09-06)  Copyright (C) 1994-2008 H. Peter Anvin
UNDI data segment at:   0009D740
UNDI data segment size: 3284
UNDI code segment at:   00090000
UNDI code segment size: 24C0
PXE entry point found (we hope) at 9D74:00F6
My Ip address seems to be C0A801C0 192.168.1.12
ip=192.168.1.12:192.168.1.250:192.168.1.254:255.255.255.0
TFTP prefix: fai/
Trying to load pxelinux.cfg/01-00-04-75-74-6e-4a
Trying to load pxelinux.cfg/C0A801C0
Loading vmlinuz-2.6.26-2-486.....................Ready.
Loading initrd.img-2.6.26-2-486..................................
Ready
Uncompressing Linux... OK, booting the Kernel.
Linux version 2.6.26-2-486 (Debian 2.6.26-4)
.
.
Done.
Mounting root file system.....
eth0: link up
RPC: Registered upd transport module.
RPC: Registered tcp transport module.
aufs 20080714
.
.
Begin: Running /scripts/live-premount ... done.
IP-Config: eth0 hardware address 00:0c:29:c9:81:38 mtu 1500 DHCP RARP
IP-Config: eth0 guessed broadcast address 192.168.1.255
IP-Config: eth0 complete (from 192.168.1.250):
 address: 192.168.1.12   broadcast: 192.168.1.255  netmask: 255.255.255.0
 gateway: 192.168.1.254  dns0     : 192.168.1.250  dns1   : 192.168.8.9
 host   : demohost
 domain : informatik.uni-koeln.de
 rootserver: 192.168.1.250 rootpath:
 filename  : pxelinux.0
Begin: Trying netboot from 192.168.1.250:/srv/fai/nfsroot ...
Begin: Trying nfsmount -o nolock -o ro 192.168.1.250:/srv/fai/nfsroot /live/image ...
.
.
          -------------------------------------------------
                Fully Automatic Installation  -  FAI

                FAI 3.3, 03 Nov 2009   (c) 1999-2009
            Thomas Lange  <lange@informatik.uni-koeln.de>
          -------------------------------------------------

Calling task_confdir
Kernel parameters: initrd=initrd.img-2.6.26-2-486 ip=dhcp root=/dev/nfs nfsroot=/srv/fai/nfsroot \
 boot=live FAI_FLAGS=verbose,sshd,createvt FAI_ACTION=install \
 FAI_CONFIG_SRC=nfs://kueppers/srv/fai/config BOOT_IMAGE=vmlinuz-2.6.26-2-486
Reading /tmp/fai/boot.log
FAI_FLAGS: verbose sshd createvt
FAI_CONFIG_SRC is set to nfs://kueppers/srv/fai/config
Configuration space kueppers:/srv/fai/config mounted to /var/lib/fai/config
Calling task_setup
Calling task_setup
FAI_FLAGS: verbose sshd createvt
Fri Oct 30 14:34:37 UTC 2009
30 Oct 14:34:37 ntpdate[3279]: step time server 134.95.4.129 offset 5.691554 sec
Press ctrl-c to interrupt FAI and to get a shell
Calling task_defclass
fai-class: Defining classes.
Executing /var/lib/fai/config/class/10-base-classes.
10-base-classes      OK.
Executing /var/lib/fai/config/class/20-hwdetect.source.
.
.
50-host-classes      OK.
List of all classes: DEFAULT LINUX I386 FAIBASE DHCPC DEMO GRUB demohost LAST
Calling task_defvar
Executing FAIBASE.var
++ FAI_ALLOW_UNSIGNED=1
++ CONSOLEFONT=
++ KEYMAP=us-latin1
++ UTC=yes
++ TIMEZONE=Europe/Berlin
++ ROOTPW='$1$kBnWcO.E$djxB128U7dMkrltJHPf6d1'
++ STOP_ON_ERROR=700
Loading keymap(s) us-latin1 ...done.
Calling task_action
FAI_ACTION: install
Performing FAI installation. All data may be overwritten!

When the copyright message of FAI is shown, the install client has mounted the nfsroot ^[5] to the clients' root directory. This is the whole file system for the client at this moment.

After task_confdir is executed, the configuration space is mounted via NFS.

Before the installation is started ($FAI_ACTION=install) the computer beeps three times. So, be careful when you hear three beeps but you do not want to perform an installation!

Begin: Mounting root file system... ...
eth0: link up

BusyBox v1.10.2 (Debian 1:1.10.2-1) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty: job control turned off
(initramfs)

$ showmount -e faiserver

If you set the variable $FAI_ACTION to sysinfo (for e.g. by using fai-chboot -S), the client will not install a new system, but will collect a lot of system information. Type ctrl-c to get a shell or use Alt-F2 or Alt-F3 and you will get another console terminal, if you have added createvt to $FAI_FLAGS.

Remote login is available via the secure shell if sshd is added to $FAI_FLAGS. The encrypted password is set with the variable $FAI_ROOTPW in make-fai-nfsroot.conf and defaults to "fai". You can create the encrypted password using mkpasswd(1) and use the crypt(3) or md5 algorithm. This is only the root password during the installation process, not for the new installed system. You can also log in without a password when using $SSH_IDENTITY. To log in from your server to the install client (named demohost in this example) use:

$ ssh root@demohost
Warning: Permanently added 'demohost,134.95.9.200' to the list of known hosts.
root@demohost's password:

You now have a running Linux system on the install client without using the local hard disk. Use this as a rescue system if your local disk is damaged or the computer can’t boot properly from hard disk. You will get a shell and you can execute various commands (dmesg, lsmod, df, lspci, …). Look at the log file in /tmp/fai. There you can find much information about the boot process.

All log files from /tmp/fai are also written to the $LOGSERVER (if not defined: the server defined by $SERVER from get-boot-info) into the directory ~fai/demohost/sysinfo/.

Two additional symbolic links are created. The symlink last points to the log directory of the last FAI action performed. The symlinks last-install and last-sysinfo point to the directory with of the last corresponding action. Examples of the log files can be found on the FAI homepage.

FAI mounts all file systems it finds on the local disks read only. It also tells you on which partition a file /etc/fstab exists. When only one file system table is found, the partitions are mounted according to this information. Here’s an example:

demohost:~# df
Filesystem      1K-blocks      Used Available Use% Mounted on
rootfs            4099064    414088   3645296  11% /
udev                10240        76     10164   1% /dev
192.168.1.250:/srv/fai/nfsroot
                  3905600    410976   3454944  11% /live/image
aufs              4099064    414088   3645296  11% /
tmpfs              193464         0    193416   0% /live
tmpfs              193464      3112    190352   2% /live/cow
faiserver:/srv/fai/config
                  3905600    410976   3454944  11% /var/lib/fai/config
/dev/sda1          241116     74519    154149  33% /target
/dev/sda9         4364212    139888   4179988   4% /target/home
/dev/sda7          553376     16840    536536   4% /target/tmp
/dev/sda8         2221628    275936   1832840  14% /target/usr
/dev/sda6          577096    172924    374856  32% /target/var
aufs               193464      2376    191243   2% /target/dev

This method can be used as a rescue environment! If you need a file system with read-write access use the rwmount command:

demohost# rwmount /target/home

If the install client boots with action sysinfo, you can also check if all information from the DHCP daemon are received correctly. The received information is written to /tmp/fai/boot.log. An example of the result of a DHCP request can be found in [setuproutines].

At any time you can reboot the computer using the command faireboot, also if logged in from remote. If the installation hasn’t finished, use faireboot -s, so the log files are also copied to the install server.

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 programs 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 ^[6] 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.

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.

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 its 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/ ^[7] 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.

The configuration is the collection of information about how exactly to install a computer. The central configuration space for all install clients is located on the install server in /srv/fai/config and its subdirectories. This will be mounted by the install clients to /var/lib/fai/config. It’s also possible to receive all the configuration data from a cvs(1), subversion (svn(1)) or Git (git(1)) repository. The following subdirectories are present and include several files:

The main installation command fai(8) uses all these subdirectories in the order listed except for hooks. The FAI package contains examples for all these configuration scripts and files in /usr/share/doc/fai-doc/examples. Copy the configuration examples to the configuration space and start an installation. These files need not belong to the root account. You can change their ownership and then edit the configuration with a normal user account.

# cp -a /usr/share/doc/fai-doc/examples/simple/* /srv/fai/config
# chown -R fai /srv/fai/config

These files contain simple configuration for some example hosts. Depending on the host name used, your computer will be configured as follows:

Start looking at these examples and study them. Then change or add things to these examples. But don’t forget to plan your own installation!

After the kernel has booted, it mounts the root file system via NFS from the install server and init(8) starts the script /usr/sbin/fai. This script controls the sequence of the installation. No other scripts in /etc/init.d/ are used.

The installation script uses many subroutines, which are defined in /usr/lib/fai/subroutines. All important tasks of the installation are called via the subroutine task appended by the name of the task as an option (e.g. task_instsoft). The subroutine task calls hooks with prefix name if available and then calls the default task (defined as task_<name> in subroutines). The default task and its hooks can be skipped on demand by using the subroutine skiptask().

Now follows the description of all default tasks, listed in the order they are executed.

After the subroutine fai_init has done some basic initialization (create RAM disk, read fai.conf and all subroutines definitions, set path, print copyright notice), the setup continues by calling the task confdir and the task setup. The command get-boot-info is called to get all information from the DHCP server. This command writes the file /tmp/fai/boot.log, which then is sourced to define the corresponding global variables. This is an example for this log file when using a DHCP server.

# cat /tmp/fai/boot.log

netdevices_all="eth0"
netdevices_up="eth0"
netdevices="eth0"
BROADCAST='192.168.1.255'
DOMAIN='localdomain'
DNSSRVS='192.168.1.1'
DNSSRVS_1='192.168.1.1'
HOSTNAME='demohost'
IPADDR='192.168.1.12'
NETWORK='192.168.1.0'
GATEWAYS='192.168.1.250'
GATEWAYS_1='192.168.1.250'
SERVER='faiserver'
NETMASK='255.255.255.0'

Additional information is passed via the kernel command line or read from fai.conf. When booting with PXE, command line parameters are created using fai-chboot(8).

If you do not boot from network card but from CD-ROM or USB stick, you may also give network parameters to the kernel via the kernel command line. Two interesting parameters are

nfsroot=<server-ip>:]<root-dir>[,<nfs-options>]

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

Those parameters are described in the documentation of the Linux kernel sources in /usr/src/linux/Documentation/nfsroot.txt.

Classes determine which configuration file to choose from a list of available templates. Classes are used in all further tasks of the installation. To determine which config file to use, an install client searches the list of defined classes and uses all configuration files that match a class name. It’s also possible to use only the configuration file with the highest priority since the order of classes define the priority from low to high. There are some predefined classes (DEFAULT, LAST and the host name), but classes can also be listed in a file or defined dynamically by scripts. So it’s easy to define a class depending on the subnet information or on some hardware that is available on the install client.

The idea of using classes in general and using certain files matching a class name for a configuration is adopted from the installation scripts by Casper Dik for Solaris. This technique proved to be very useful for the SUN workstations, so I also use it for the fully automatic installation of Linux. One simple and very efficient feature of Casper’s scripts is to call a command with all files (or on the first one) whose file names are also a class. The following loop implements this function in pseudo shell code:

for class in $all_classes; do
if [ -r $config_dir/$class ]; then
   your_command $config_dir/$class
   # exit if only the first matching file is needed
fi
done

Therefore it is possible to add a new file to the configuration without changing the script. This is because the loop automatically detects new configuration files that should be used. Unfortunately cfengine does not support this nice feature, so all classes being used in cfengine also need to be specified inside the cfengine scripts. Classes are very important for the fully automatic installation. If a client belongs to class A, we say the class A is defined. A class has no value, it is just defined or undefined. Within scripts, the variable $classes holds a space separated list with the names of all defined classes. Classes determine how the installation is performed. For example, an install client can be configured to become an FTP server by just adding the class FTP to it.

Mostly a configuration is created by only changing or appending the classes to which a client belongs, making the installation of a new client very easy. Thus no additional information needs to be added to the configuration files if the existing classes suffice for your needs. There are different possibilities to define classes:

The last option is a very nice feature, since these scripts will define classes automatically. For example, several classes are defined only if certain hardware is identified. We use Perl and shell scripts to define classes. All names of classes, except the host name, are written in uppercase. They must not contain a hyphen, a hash or a dot, but may contain underscores. A description of all classes can be found in /usr/share/doc/fai-doc/classes_description.txt.

Host names should rarely be used for the configuration files in the configuration space. Instead, a class should be defined and then added for a given host. This is because most of the time the configuration data is not specific for one host, but can be shared among several hosts.

The task defclass calls the script fai-class(1) to define classes. Therefore, scripts matching [0-9][0-9]* in $FAI/class are executed. Additionally, a file with the host name may contain a list of classes. For more information on defining class, read the manual pages for fai-class(1).

The list of all defined classes is stored in the variable $classes and saved to /tmp/fai/FAI_CLASSES. The list of all classes is transferred to cfengine, so it can use them too. The script 10-base-classes (below is a stripped version) is used to define classes depending on the host name. First, this script defines the class with the name of the hardware architecture in uppercase letters.

10-base-classes:

# echo architecture and OS name in upper case. Do NOT remove these two lines
uname -s | tr '[:lower:]' '[:upper:]'
dpkg --print-architecture | tr /a-z/ /A-Z/

[ -f /etc/RUNNING_FROM_FAICD ] && echo "FAICD"

# use a list of classes for our demo machine
case $HOSTNAME in
    demohost)
        echo "FAIBASE GRUB DHCPC DEMO" ;;
    gnomehost)
        echo "FAIBASE GRUB DHCPC DEMO XORG GNOME";;
    *)
        echo "FAIBASE GRUB DHCPC" ;;
esac

The script 20-hwdetect.source uses the default Debian commands to detect hardware and to load some kernel modules. If some specific hardware is found, it can also define a new class for it. You can find messages from modprobe in /tmp/fai/kernel.log and on the fourth console terminal by pressing Alt-F4.

The task defvar defines the variables for the install client. Variables are defined by scripts in class/*.var. All global variables can be set in DEFAULT.var. For certain groups of hosts use a class file or for a single host use the file +$HOSTNAME+.var. Also here, it’s useful to study all the examples.

The following variables are used in the examples and may also be useful for your installation:

Read the manual page of setup-storage(8) for a detailed description of the new format. This is used by default since FAI 3.2.8.

Before installing packages, FAI will add the content of all files named package_config/*.asc to the list of apt keys. If your local repository is signed by your keyid AB12CD34 you can easily add this key, so FAI will use it during installation. Use this command for creating the .asc file:

faiserver$ gpg -a --export AB12CD34 > /srv/fai/config/package_config/myrepo.asc

The script install_packages(8) installs the selected software packages. It uses all configuration files in $FAI/package_config whose file name matches a defined class. The syntax is very simple.

# an example package class

PACKAGES taskinst
german

PACKAGES aptitude
adduser netstd ae
less passwd

PACKAGES remove
gpm xdm

PACKAGES aptitude GRUB
lilo- grub

PACKAGES dselect-upgrade
ddd                     install
a2ps                    install

Comments are starting with a hash (#) and are ending at the end of the line. Every command begins with the word PACKAGES followed by a command name. The command defines which command will be used to install the packages named after this command. The list of all available commands can be listed using install_packages -H. Supported package tools are: aptitude, apt-get, smart, y2pmsh, yast, yum, urpm, rpm

Multiple lines with lists of space separated names of packages follow the PACKAGES lines. All dependencies are resolved. Packages with suffix - (eg. lilo-) will be removed instead of installed. The order of the packages is of no matter. If you like to install packages from another release than the default, you can append the release name to the package name like in openoffice.org/etch-backports. You can also specify a certain version like apt=0.3.1. More information on these features are described in aptitude(8).

A line which contains the PRELOADRM commands, downloads a file using wget(1) into a directory before installing the packages. Using the file: URL, this file is copied from $FAI_ROOT to the download directory. For example the package realplayer needs an archive to install the software, so this archive is downloaded to the directory /root. After installing the packages this file will be removed. If the file shouldn’t be removed, use the command PRELOAD instead.

It’s possible to append a list of class names after the command for apt-get. So this PACKAGE command will only be executed when the corresponding class is defined. So you can combine many small files into the file DEFAULT. WARNING! Use this feature only in the file DEFAULT to keep everything simple. See this file for some examples.

If you want to remove a package name from a certain class was part of this class before, you should not remove the package name from the class file, but instead append a dash (-) to it. This will make sure that the package is remove during a softupdate on hosts which were installed using the old class definition which included this package name.

If you specify a package that does not exist this package will be removed from the installation list when the command install is used.

The default set of scripts in $FAI/scripts is only an example. But they should do a reasonable job for your installation. You can edit them or add new scripts to match your local needs.

The command fai-do-scripts(1) is called to execute all scripts in this directory. If a directory with a class name exists, all scripts matching [0-9][0-9]* are executed in alphabetical order. So it’s possible to use scripts of different languages (shell, cfengine, Perl,..) for one class.

Changing the boot sequence is normally done in the BIOS setup. But you can’t change the BIOS from a running Linux system as far as I know. If you know how to perform this, please send me an email. But there’s another way of swapping the boot device of a running Linux system.

So, normally the boot sequence of the BIOS will remain unchanged and your computer should always boot first from its network card and the second boot device should be the local disk. Then, it will get an install kernel image from the install server, when an installation should be performed, or we can tell pxelinux to boot from local disk. This is done using fai-chboot(8).

Here is how to set up a 3Com network card as first boot device. Enable LAN as first boot device in the BIOS.

Boot From LAN First: Enabled
Boot Sequence      : C only

Then enter the MBA setup of the 3Com network card and change it as follows:

Default Boot           Local
Local Boot             Enabled
Message Timeout        3 Seconds
Boot Failure Prompt    Wait for timeout
Boot Failure           Next boot device

This will enable the first IDE hard disk as second boot device after the network card.

Hooks let you specify functions or programs which are run at certain steps of the installation process. Before a default task is called, FAI searches for existing hooks for this task and executes them. As you might expect, classes are also used when calling hooks. Hooks are executed for every defined class. You only have to create the hook with the name for the desired class and it will be used. If several hooks for a task exists, they are called in the order defined by the classes. If debug is included in $FAI_FLAG the option -d is passed to all hooks, so you can debug your own hooks. If some default tasks should be skipped, use the subroutine skiptask and a list of default tasks as parameters. The example partition.DISKLESS skips some default tasks.

The directory $FAI/hooks/ contains all hooks. A hook is an executable file following the naming scheme taskname.CLASSNAME[.source] (e.g. partition.DISKLESS or partition.DISKLESS.source), a task name and a class name separated by a dot, optionally followed by .source. The task name specifies which task to precede executing this hook, if the specified class is defined for the installing client. See section [tasks] for a complete list of default tasks that can be used.

In our example, the hook partition.DISKLESS is called for every client belonging to the class DISKLESS before the local disks would be partitioned. If it should become a diskless client, this hook can mount remote file systems via NFS and create a /tmp/fai/fstab. After that, the installation process will not try to partition and format a local hard disk, because a file /tmp/fai/fstab already exists.

A hook of the form hookprefix.classname can’t define variables for the installation script, because it’s a subprocess. But you can use any binary executable or any script you wrote. Hooks that have the suffix .source (e.g. partition.DEFAULT.source) must be Bourne shell scripts and are sourced. So it’s possible to redefine variables for the installation scripts.

In the first part of FAI, all hooks with prefix confdir are called. Since the configuration directory $FAI is mounted in the default task confdir, the hooks for this task are the only hooks located in $nfsroot/$FAI/hooks on the install server. All other hooks are found in $FAI_CONFIGDIR/hooks on the install server.

All hooks that are called before classes are defined can only use the following classes: DEFAULT $HOSTNAME LAST. If a hook for class DEFAULT should only be called if no hook for class $HOSTNAME is available, insert these lines to the default hook:

hookexample.DEFAULT:

#! /bin/sh

# skip DEFAULT hook if a hook for $HOSTNAME exists
scriptname=$(basename $0 .DEFAULT)
[-f $FAI/hooks/$scriptname.$HOSTNAME ] && exit
# here follows the actions for class DEFAULT
.
.

Some examples for what hooks could be used:

If the client can’t successfully boot from the network card, use tcpdump(8) to look for Ethernet packets between the install server and the client. Search also for entries in several log files made by tftpd(8) and dhcpd3(8) :

faiserver$ egrep "tftpd|dhcpd" /var/log/*

Sometimes the installation seems to stop, but often there’s only a postinstall script of a software package that requires manual input from the console. Change to another virtual terminal and look which process is running with tools like top(1) and pstree(1). You can add debug to FAI_FLAGS to make the installation process show all output from the postinst scripts on the console and get its input also from the console. Don’t hesitate to send an email to the mailing list or to fai@fai-project.org if you have any questions. Sample log files from successfully installed computers are available on the FAI homepage.

FAI is creating several log files. During installation they are stored in /tmp/fai on the install client itself. At the end of the installation they will be copied to the install server (see [isavelog]). After the install client rebooted into his newly installed system, you can find the FAI logs in /var/log/fai. Log files are also created when doing the softupdate or dirinstall action.

These a some log files which are created by FAI.

If the installation process finishes, the hook savelog.LAST.source searches all log files for common errors and writes them to the file error.log. So, you should first look into this file for errors. Also the file status.log give you the exit code of the last command executed in a script. To be sure, you should look for more details in all log files.

The example of a Beowulf cluster consists of one master node and 25 clients. A big rack was assembled which all the cases were put into. A keyboard and a monitor, which are connected to the master server most of the time, were also put into the rack. But since we have very long cables for a monitor and a keyboard, they can also be connected to all nodes if something has to be changed in the BIOS, or when looking for errors when a node does not boot. Power supply is another topic you have to think about. Don’t connect many nodes to one power cord and one outlet. Distribute them among several breakout boxes and outlets. And what about the heat emission? A dozen nodes in a small room can create too much heat, so you will need an air conditioner. Will the power supplies of each node go to stand-by mode or are all nodes turned on simultaneously after a power failure?

All computers in this example are connected to a Fast Ethernet switch. The master node (or master server) is called nucleus. It has two network cards. One for the connection to the external Internet, one for the connection to the internal cluster network. If connected from the external Internet, it’s called nucleus, but the cluster nodes access the master node with the name atom00, which is a name for the second network interface. The master server is also the install server for the computing nodes. A local Debian mirror will be installed on the local hard disk. The home directories of all user accounts are also located on the master server. It will be exported via NFS to all computing nodes. NIS will be used to distribute account, host, and printer information to all nodes.

All client nodes atom01 to atom25 are connected via the switch with the second interface card of the master node. They can only connect to the other nodes or the master, but can’t communicate to any host outside their cluster network. So, all services (NTP, DNS, NIS, NFS, …) must be available on the master server. I chose the class C network address 192.168.42.0 for building the local Beowulf cluster network. You can replace the subnet 42 with any other number you like. If you have more than 253 computing nodes, choose a class A network address (10.X.X.X).

In the phase of preparing the installation, you have to boot the first install client many times, until there’s no fault in your configuration scripts. Therefore you should have physical access to the master server and one client node. So, connect both computers to a switch box, so one keyboard and monitor can be shared among both.

The master server will be installed by hand if it is your first computer installed with Debian. If you already have a host running Debian, you can also install the master server via FAI. Create a partition on /files/scratch/debmirror for the local Debian mirror with more than 22 GB space available.

# Beowulf cluster connection
auto eth1
iface eth1 inet static
address 192.168.42.250
netmask 255.255.255.0
broadcast 192.168.42.255

# create these entries with the Perl one liner
# perl -e 'for (1..25) {printf "192.168.42.%s atom%02s\n",$_,$_;}'

# Beowulf nodes
# atom00 is the master server
192.168.42.250 atom00
192.168.42.1 atom01
192.168.42.2 atom02

beowcluster 192.168.42.0

# adduser tom
# addgroup linuxadmin

# adduser tom linuxadmin

/etc/ypserv.securenets:

# Always allow access for localhost
255.0.0.0       127.0.0.0
# This line gives access to the Beowulf cluster
255.255.255.0 192.168.42.0

master# cd /var/yp; make

/files/scratch/debmirror *(ro)

nucleus:/# apt-get install ntp tftpd-hpa dhcp3-server \
  nfs-kernel-server etherwake fai
nucleus:/# tasksel -q -n install dns-server
nucleus:/# apt-get dselect-upgrade

NFSROOT_ETC_HOSTS="192.168.42.250 atom00"

 shell stream tcp  nowait.300  root /usr/sbin/tcpd /usr/sbin/in.rshd
 login stream tcp  nowait.300  root /usr/sbin/tcpd /usr/sbin/in.rlogind

# chgrp -R linuxadmin /srv/tftp/fai; chmod -R g+rwx /srv/tftp/fai
# cp /usr/share/doc/fai-doc/examples/utils/* /usr/local/bin

$ fai-chboot -IFv atom01

The following tools are useful for a Beowulf cluster:

These are some common tools for a cluster environment:

Wake on LAN is a very nice feature to power on a computer without having physical access to it. By sending a special ethernet packet to the network card, the computer will be turned on. The following things have to be done, to use the wake on LAN (WOL) feature.

To wake up a computer use the command etherwake(8).

To install a computer with a 32bit i386 system, you need an i386 nfsroot. Creating this 32bit nfsroot on an install server runnning amd64 is quite simple. Install and set up the FAI packages. Then copy your FAI config files to a new subdirectory.

faiserver# cp -a /etc/fai /etc/fai-i386

Edit the variable $FAI_DEBOOTSTRAP_OPTS in /etc/fai-i386/make-fai-nfsroot.conf and add the option --arch i386. Also choose a different directory for your new nfsroot. Here are the two lines after editing.

NFSROOT=/srv/fai/nfsroot-i386
FAI_DEBOOTSTRAP_OPTS="--arch i386 --exclude=info"

Now call make-fai-nfsroot which creates the 32bit i386 nfsroot in /srv/fai/nfsroot-i386

faiserver# make-fai-nfsroot -v -C/etc/fai-i386

Creating a partitial mirror using fai-mirror(1) that is needed for a bootable CD or USB stick is also possible on a different architecture. Due to a bug in apt-move (#441231), you have to specify the architecture when calling fai-mirror.

$ export MAXPACKAGES=800
$ fai-mirror -a i386 -v -cDEFAULT,FAIBASE,I386 /srv/mirror-i386

That’s all!

There’s some stuff on http://www.layer-acht.org/fai. Most notably there are hooks for partitioning and config-files to set up bootloaders for oldworld and newworld.

There’s one big IA64 Beowulf cluster running which was installed with FAI. Only the partitioning part has to be replaced by a short script, since sfdisk is not available on IA64. This should not be need any more since the partitioning tool setup-storage(8) works on all architectures, were parted is supported.

You can install all sorts of Linux distributions from a single Debian nfsroot. Therefore you have to create a base.tgz of the distribution you like to install and place it info the basefiles directory. Then name it UBUNTU910.tar.gz for example. An install client which belongs to the class UBUNTU910 then extracts this base file into its empty file system. Additionally you have to adjust the sources.list or similar configuration files which are needed for specifying the location of the package repository.

All FAI packages are available in Ubuntu and are used by a large number of people since many version.

Many people are interested in FAI for other (mostly RPM based) Linux distributions. I made some research and it should not be much work to implement it. But I need more help to implement it. If you are interested and would like to help me, please send an email to fai@fai-project.org.

A brief description how to install SLES9 with FAI is available at http://www.sourcecode.de/install_sles_with_fai.

There are also some information in the faiwiki.

Although FAI is architecture independent, there are some packages which are only available for certain architectures (e.g. silo, sparc-utils).

SUN SPARC computers can boot from their boot prompt. To boot a SUN use:

boot net:dhcp - ip=::::::dhcp

You have to convert the kernel image from ELF format to a.out format. Use the program elftoaout (mentioned in the FAQ). The symlink to the kernel image to be booted is not the host name.

A success report as of 2001 is available at http://www.opossum.ch/fai/.

FAI has also been ported for use with SUN Solaris OS installations in cooperation with Solaris jumpstart. This was done using FAI 2.8.4 and Solaris 9. Get the FAI sources from FAI 2.8.4 and change to the sunos directory. There you can call make which creates the tarball /tmp/fai-solaris.tar.gz. You have to read the file README.sunos and have some knowledge about Solaris jumpstart. The Solaris support was removed in FAI 2.9.

The file format of the configuration files in disk_config and package_config are different than those for Linux.

If you have some chroot environments to install, or a virtualization environment where you neither can nor want to run a normal Debian Installer in to get to a working system (for example, Xen guest domains), there is the FAI action dirinstall. By calling

faiserver# fai <options> dirinstall <target-directory>

and using either the option -c <classes> or -N you get a FAI installation, without the partitioning action, right into the target directory. The host name for the target installation can be specified using -u <host-name>

This, for example, can be used to combine FAI with the tool xen-tools, which helps you to build Xen guest domains. xen-tools are very nice for generating configuration files and block devices for new guests based on simple commands and/or configuration files, but they can only assign one role per installation for customization. FAI-users need and want more, as they are used to have the class system. They get them even in xen-tools installations, by using the following code as a xen-tools role script:

#!/bin/sh
TARGET=$1
CMD="fai -N  -v -u ${hostname} dirinstall $TARGET"
echo running $CMD
$CMD

Then, you will want to set the variable install=0 the xen-tools config for that host (in previous versions of xen-tools, this was no-install=1).

FAI is even usable for system updates, using the same configuration as if initially installing. System update means updating the running system without doing a re-installation. An updated client will almost look like a newly installed machine, though all local data is preserved (except of course newer configuration files introduced in the FAI config).

# fai -v softupdate

        $ROOTCMD invoke-rc.d $somedaemon reload

        $ROOTCMD invoke-rc.d $somedaemon restart

FAI_BACKUPDIR=$LOGDIR/backup