7. Theory of operation

Booting a diskless workstation involves several steps. Understanding what is happening along the way will make it much easier to solve problems, should they arise.

This description of the events is assuming that there is a server configured to handle the booting of a workstation.

1. When you turn on the workstation, it will go through it's "Power On Self Test" (POST) and the bootcode in the eprom on the network card will begin executing.
2. The bootcode will attempt to detect a network card. Once it detects the card, it will initialize it.
3. The bootcode will then broadcast a bootp request to the local network. The request will include the MAC address of the network card. (DHCP can also be used)
4. The inetd process on the server will see the broadcast and invoke the bootpd daemon to respond to the request.
5. The bootpd process will read it's configuration file, /etc/bootptab, and locate the entry that matches the MAC address that was sent in the request. Once the entry is found, it will be put into a reply packet and sent back to the workstation that requested the information. Several pieces of information will be passed back in the reply, the items that are important at this point are:
   1. IP address assigned to the workstation ('ip=')
   2. NETMASK setting for the local network ('sm=')
   3. Bootfile home directory ('hd=')
   4. The name of the kernel to download ('bf=')
6. The bootcode will receive the reply from bootp and it will configure the TCP/IP interface in the network card with the parameters that were supplied.
7. The bootcode will then send a TFTP request to the server to begin downloading the kernel from the server.
8. Once the kernel has been completely downloaded to the workstation, the bootcode will do a jump to the starting code in the kernel.
9. The kernel will then start executing, initializing the entire system and all of the peripherals.
10. The bootcode can pass information to the kernel. It does this by constructing a kernel command line, similar to the way LILO passes parameters with the append= parameter. If the bootrom is not setup properly, or if the kernel hasn't been tagged properly with mknbi-linux, then the kernel can issue a bootp request to obtain the info on it's own.
11. If the kernel does need to send a bootp/dhcp request, the server will respond with another reply packet, containing the information that the kernel needs to continue. The relevant items in the reply this time are:
    1. IP address assigned to the workstation ('ip=')
    2. NETMASK setting for the local network ('sm=')
    3. The root directory to be mounted via NFS ('rp=')
    4. The gateway ('gw=')
    5. The DNS server ('ds=')
    6. The hostname of the workstation (The value of the first field in the bootptab entry)
    Once all of the above parameters have been passed back to the workstation, the network interface will be configured and brought up.
12. The root filesystem will be mounted via NFS. This filesystem will be mounted read-only. We do this because we may have many workstations mounting the same filesystem, and we don't want any of the workstations to modify the contents of the root filesystem.
13. At this point, control will be passed from the kernel to the 'init' process.
14. init will read the /etc/inittab file and begin setting up the environment.
15. One of the first items in the inittab file is the rc.local command that will be run while the workstation is in the 'sysinit' state.
16. The rc.local script will create a 1mb ramdisk to contain all of the things that need to be written to or modified in any way.
17. This ramdisk will be mounted as the /tmp directory. Any files that need to be written will actually exist in the /tmp directory, and there are symbolic links pointing to these files. For example, when the workstation is running, it will try to modify the permissions on the /dev/tty0 device node. If the device node actually existed in the /dev directory, the permissions would not be modifiable, because the root filesystem is read-only. So, we have created symbolic links for all of the files and created the actual files/nodes in the /tmp directory (which is writeable).
18. The /proc filesystem will be mounted.
19. The loopback network interface will be configured.
20. Several directories will be created under the /tmp filesystem for holding some of the transient files that are needed while the system is running. Directories such as:
    1. /tmp/compiled
    2. /tmp/var
    3. /tmp/var/run
    4. /tmp/var/log
    5. /tmp/var/lock
    6. /tmp/var/lock/subsys
    will all be created.
21. The /etc/XF86Config file will be generated based on entries in the /tftpboot/lts/ltsroot/etc/lts.conf configuration file. This is where information about the type of mouse, and other X parameters are combined to create the config file for X.
22. The /tmp/start_ws script will be created. This script is responsible for starting the X server. When this script starts the X server, it will direct it to send XDMCP queries to the XDM server. This is Based on information found in the /tftpboot/lts/ltsroot/etc/lts.conf file.
23. The /tmp/syslog.conf file will be created. This file will contain information telling the syslogd daemon which host on the network to send the logging information to. The syslog host is specified in the lts.conf file. There is a symbolic link called /etc/syslog.conf that points to the /tmp/syslog.conf file.
24. The syslogd daemon is started, using the config file that was just created.
25. Control is passed back to init. Init will then look at the initdefault entry to determine which runlevel to enter.
26. If runlevel 3 is specified, then a shell will be started on the console. This is good for doing trouble shooting.
27. If runlevel 5 is specified, then the /tmp/start_ws script will be invoked, which will either bringup X-windows, or start a telnet session to the server, depending on the value of the configuration entry 'UI_MODE'.
28. If GUI mode is chosen, then when X is started, it will send an XDMCP query to the server. There should be a display manager running on the server, waiting for XDMCP requests. Examples of display managers are XDM, GDM and KDM. The display manager will then send a login dialog box to the screen.
29. Once the user logs in, they will be running processes on the server. That is, if they bring up an xterm session, it will be running on the server, and it will be displaying it's output on the workstation.