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.
(In this document we'll use the terms client and workstation
interchangeably.)
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.
