2. General Overview

An NFS-mounted root filesystem is typically most useful in two situations:

• A system administrator may wish to aggregate storage for multiple workstations in order to simplify maintenance, improve security and reliability, and/or make more economical use of limited storage capacity. In this scenario, a single, large server may host a dozen or more workstations; all of the systems can be regularly backed up from a central location, and individual clients are less prone to damage by unsophisticated users or attack by malicious parties with physical access. (Of course, if the server itself is compromised, then so are all of the clients.)
• An embedded system may not have a disk, an IDE interface, or even a PCI bus. Even if it does, during development it may be too unstable to use the disk, and a ramdisk may be too small to include all of the necessary utilities or too large (as a part of the kernel image) to allow for rapid turnaround during testing and development. An NFS root allows quick kernel downloads, helps ensure filesystem integrity (since the server is basically impervious to crashes by the client), and provides virtually infinite storage.

However, there are two small problems from the client's perspective:

• It must find out its own IP address and possibly also the rest of the ethernet configuration (gateway, netmask, name servers, etc.).
• It must know or discover both the IP address of the NFS server and the mount path (on the server) to the exported root filesystem.

The current implementation of NFSROOT in the Linux kernel (as of 2.4.x) allows for several approaches, including:

• The complete ethernet configuration, including the NFS-path to be mounted, may be passed as parameters to the kernel via LILO, LOADLIN, or a hard-coded string within linux/arch/i386/kernel/setup.c (or its equivalent for other architectures).
• The IP address may be discovered by RARP and the NFS-path passed via kernel parameters.
• The IP address may be discovered by RARP, with the NFS-path derived from the RARP server and the just-granted IP address (loosely speaking, ``mount -t nfs <RARP-server>:/tftpboot/<IP-address-of-client>/dev/nfs'').
• The client configuration may be discovered by BOOTP.
• The client configuration may be discovered by DHCP.

Since the most common dynamic-address protocol these days is DHCP, its addition as an option in kernels 2.2.19 and 2.4.x (3 < x <= 14) is particularly welcome.

Before starting to set up a diskless environment, you should decide if you will be booting via LILO, LOADLIN, or a custom, embedded bootloader. The advantage of using something like LILO is flexibility; the disadvantage is speed--booting a Linux kernel without LILO is faster. This may or may not be a consideration.