| << | < | > | >> | Version 1.0 |
A diskless PC offers several challenges, including initial boot up, and then running an operating system which is generally expecting access to a hard drive of some sort. This section describes the theory behind how a diskless workstation operates, focusing on a Linux based diskless workstation.
In a PC without a hard drive an alternative means of booting the machine must be found. Depending on the hardware being used there are several options for booting the machine.
Increasingly modern computers include a BIOS option to boot from the network using either PXE (the Preboot Execution Environment, a DHCP extension promoted by Intel Corporation), or RPL (Remote Program Loading, a Novell Netware based boot method). For those that don't, most network cards include a socket for a small boot rom which can be programmed to load an operating system over the network. The Etherboot, and the older Netboot project provide the ability to build suitable ROM images for many widely used network cards. The boot process is similar in all of these cases, and will be discussed further below.
Some PCs, particularly single board PCs and smaller PCs intended for embedded applications include a socket for a Disk-on-Chip chip. These are available in various sizes from approximately 4MB up to about 32MB. They appear to the BIOS as another disk, and thus fairly standard disk-booting methods can be used. The approach often taken is to boot a version of DOS (eg, FreeDOS), and then use syslinux or loadlin or similar to boot from DOS into another operating system.
If the computer is not completely without disks, and includes a floppy drive or a CD-ROM drive, then these can be used in booting the machine. They can be used to directly load the operating system into memory (either just the kernel or the entire runtime environment from a small Linux distribution), or just enough code to boot from the network. The latter is particularly useful when testing the network booting setup. In particular Etherboot includes the option to create a DOS .COM file which can be run to start the network booting process. Using a floppy that can boot some version of DOS and an Etherboot .COM file, the network booting can be tested from a floppy disk.
Network booting a PC workstation on an IP based network requires a server on the network that supports both DHCP (or in some cases just bootp) and TFTP (the Trivial File Transfer Protocol), to provide configuration information and allow transfer of initial boot files. (RPL requires a slightly different setup, but the underlying principles are the same.) DHCP (the Dynamic Host Configuration Protocol) is an address discovery (or allocation) protocol with the ability to also pass other initial configuration information to the booting host. TFTP is a UDP based protocol which allows the client to request a file one block at a time. PXE booting requires a PXE server, which is essentially a DHCP server on steroids -- the PXE server offers all the information usually set through DHCP as well as additional configuration services. Most PXE clients can be "faked out" with a DHCP server configured to return some additional information in the responses. The following discussion assumes an IP based network and booting with PXE, Etherboot or Netboot. RPL booting is similar, but uses a Netware based network.
The network boot code gets control after the basic POST checks have been performed and the basic hardware initialisation has been performed. When the network booting is included in the BIOS, a BIOS setup option will generally enable transfer of control to the network boot code, either instead of booting from the hard drive or before hard drive booting is tried. In the case of a network card boot ROM, the boot ROM will be found during the BIOS scan for card initialisation ROMs and the ROM initialisation code will hook into the BIOS boot code to take control as soon as the booting process begins.
Once the network booting code has control, it first sends out either a DHCP or a bootp request to the network to obtain (a) an IP address to use, and other network card setup information, and (b) the pathname of the boot file to load. PXE booting is similar, except that PXE expects to get some PXE-specific information back in the DHCP query, including the PXE version in use. Having obtained this information it initialises the network card, and then uses TFTP (the Trivial File Transfer Protocol) to download the boot file, block by block.
The first file retrieved over the network is generally either a second
stage boot loader (eg, pxelinux in the case of a PXE boot), or a
specially tagged kernel (Etherboot/Netboot). A second stage boot loader
will generally load a configuration file over the network (eg, a file
from the pxelinux.cfg subdirectory in the case of pxelinux)
to control what it does next. Typically after that it will use TFTP to
download a kernel image, and optionally an initial ram disk image.
Once the kernel has been retrieved, and uncompressed, control will be transfered to it, and the booting process can continue.
The following discussion assumes a Linux 2.2 based kernel; startup with other operating systems or kernel versions will be similar but not identical.
When the kernel receives control it starts by detecting and initialising the hardware, including the CPU, memory, and network card. After this, if it has an initial ram disk, it mounts the ram disk as the root file system, and transfers control to the init process on that ram disk, which continues the boot process. If there is no initial ram disk, and the root file system is to be mounted over the network using NFS, then the kernel performs a DHCP (or bootp) request to get its IP address, and possibly the location to mount (it can also come from the kernel boot flags), and then performs a NFS mount of the root file system from that location. Once mounted it transfers control to the init process on the NFS-mounted root file system, to continue booting.
From here the boot process is basically identical to that of a machine booting from a hard drive. That is init will run some startup scripts which set various things up on the machine, and then start up various daemons and applications. Generally the programs started will include a user-mode DHCP daemon (to look after renewing the DHCP lease on the IP address), as well an X server to allow access to applications through the X Window System (X11).
When the X server is started it will send out a XDMCP broadcast to locate XDM servers. Once an XDM server is located, the XDM server ask the X server to display a login window on the screen, and wait for a user to log in. When a user logs in their login scripts will run on the XDM server, and any applications they run will (by default) run on the XDM server, displayed over the network to the X server on the workstation, using the native remote display support in the X Window System protocol.
| << | < | > | >> | Copyright © 2000 Naos Limited |