old-www/HOWTO/NFS-Root-2.html

82 lines
3.7 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>NFS-Root mini-HOWTO: General Overview</TITLE>
<LINK HREF="NFS-Root-3.html" REL=next>
<LINK HREF="NFS-Root-1.html" REL=previous>
<LINK HREF="NFS-Root.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="NFS-Root-3.html">Next</A>
<A HREF="NFS-Root-1.html">Previous</A>
<A HREF="NFS-Root.html#toc2">Contents</A>
<HR>
<H2><A NAME="s2">2. General Overview</A></H2>
<P>An NFS-mounted root filesystem is typically most useful in two situations:
<UL>
<LI>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.)</LI>
<LI>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.</LI>
</UL>
(In this document we'll use the terms <EM>client</EM> and <EM>workstation</EM>
interchangeably.)
<P>
<P>However, there are two small problems from the client's perspective:
<UL>
<LI>It must find out its own IP address and possibly also the
rest of the ethernet configuration (gateway, netmask, name servers, etc.).</LI>
<LI>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.</LI>
</UL>
<P>
<P>The current implementation of <EM>NFSROOT</EM> in the Linux kernel (as of
2.4.x) allows for several approaches, including:
<UL>
<LI>The complete ethernet configuration, including the <EM>NFS</EM>-path
to be mounted, may be passed as parameters to the kernel via
<B>LILO</B>, <B>LOADLIN</B>, or a hard-coded string within
<CODE>linux/arch/i386/kernel/setup.c</CODE> (or its equivalent for other
architectures).</LI>
<LI>The IP address may be discovered by <EM>RARP</EM> and the <EM>NFS</EM>-path
passed via kernel parameters.</LI>
<LI>The IP address may be discovered by <EM>RARP</EM>, with the <EM>NFS</EM>-path
derived from the <EM>RARP</EM> server and the just-granted IP address
(loosely speaking, ``<CODE>mount -t nfs
&lt;<EM>RARP-server</EM>&gt;:/tftpboot/&lt;<EM>IP-address-of-client</EM>&gt;/dev/nfs</CODE>'').</LI>
<LI>The client configuration may be discovered by <EM>BOOTP</EM>.</LI>
<LI>The client configuration may be discovered by <EM>DHCP</EM>.</LI>
</UL>
<P>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 &lt; x &lt;= 14)
is particularly welcome.
<P>Before starting to set up a diskless environment, you should decide if
you will be booting via <B>LILO</B>, <B>LOADLIN</B>, or a custom, embedded
bootloader. The advantage of using something like <B>LILO</B> is flexibility;
the disadvantage is speed--booting a Linux kernel without <B>LILO</B> is
faster.
This may or may not be a consideration.
<P>
<HR>
<A HREF="NFS-Root-3.html">Next</A>
<A HREF="NFS-Root-1.html">Previous</A>
<A HREF="NFS-Root.html#toc2">Contents</A>
</BODY>
</HTML>