Mounting the root filesystem via NFS (nfsroot)===============================================Written 1996 by Gero Kuhlmann <gero@gkminix.han.de>Updated 1997 by Martin Mares <mj@atrey.karlin.mff.cuni.cz>If you want to use a diskless system, as an X-terminal or printerserver for example, you have to put your root filesystem onto anon-disk device. This can either be a ramdisk (see initrd.txt inthis directory for further information) or a filesystem mountedvia NFS. The following text describes on how to use NFS for theroot filesystem. For the rest of this text 'client' means thediskless system, and 'server' means the NFS server.1.) Enabling nfsroot capabilities -----------------------------In order to use nfsroot you have to select support for NFS duringkernel configuration. Note that NFS cannot be loaded as a modulein this case. The configuration script will then ask you whetheryou want to use nfsroot, and if yes what kind of auto configurationsystem you want to use. Selecting both BOOTP and RARP is safe.2.) Kernel command line -------------------When the kernel has been loaded by a boot loader (either by loadlin,LILO or a network boot program) it has to be told what root fs deviceto use, and where to find the server and the name of the directoryon the server to mount as root. This can be established by a coupleof kernel command line parameters:root=/dev/nfs This is necessary to enable the pseudo-NFS-device. Note that it's not a real device but just a synonym to tell the kernel to use NFS instead of a real device.nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] If the `nfsroot' parameter is NOT given on the command line, the default "/tftpboot/%s" will be used. <server-ip> Specifies the IP address of the NFS server. If this field is not given, the default address as determined by the `ip' variable (see below) is used. One use of this parameter is for example to allow using different servers for RARP and NFS. Usually you can leave this blank. <root-dir> Name of the directory on the server to mount as root. If there is a "%s" token in the string, the token will be replaced by the ASCII-representation of the client's IP address. <nfs-options> Standard NFS options. All options are separated by commas. If the options field is not given, the following defaults will be used: port = as given by server portmap daemon rsize = 1024 wsize = 1024 timeo = 7 retrans = 3 acregmin = 3 acregmax = 60 acdirmin = 30 acdirmax = 60 flags = hard, nointr, noposix, cto, acip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf> This parameter tells the kernel how to configure IP addresses of devices and also how to set up the IP routing table. It was originally called `nfsaddrs', but now the boot-time IP configuration works independently of NFS, so it was renamed to `ip' and the old name remained as an alias for compatibility reasons. If this parameter is missing from the kernel command line, all fields are assumed to be empty, and the defaults mentioned below apply. In general this means that the kernel tries to configure everything using both RARP and BOOTP (depending on what has been enabled during kernel confi- guration, and if both what protocol answer got in first). <client-ip> IP address of the client. If empty, the address will either be determined by RARP or BOOTP. What protocol is used de- pends on what has been enabled during kernel configuration and on the <autoconf> parameter. If this parameter is not empty, neither RARP nor BOOTP will be used. <server-ip> IP address of the NFS server. If RARP is used to determine the client address and this parameter is NOT empty only replies from the specified server are accepted. To use different RARP and NFS server, specify your RARP server here (or leave it blank), and specify your NFS server in the `nfsroot' parameter (see above). If this entry is blank the address of the server is used which answered the RARP or BOOTP request. <gw-ip> IP address of a gateway if the server is on a different subnet. If this entry is empty no gateway is used and the server is assumed to be on the local network, unless a value has been received by BOOTP. <netmask> Netmask for local network interface. If this is empty, the netmask is derived from the client IP address assuming classful addressing, unless overridden in BOOTP reply. <hostname> Name of the client. If empty, the client IP address is used in ASCII notation, or the value received by BOOTP. <device> Name of network device to use. If this is empty, all devices are used for RARP and BOOTP requests, and the first one we receive a reply on is configured. If you have only one device, you can safely leave this blank. <autoconf> Method to use for autoconfiguration. If this is either 'rarp' or 'bootp', the specified protocol is used. If the value is 'both' or empty, both protocols are used so far as they have been enabled during kernel configura- tion. 'off' means no autoconfiguration. The <autoconf> parameter can appear alone as the value to the `ip' parameter (without all the ':' characters before) in which case auto- configuration is used.3.) Kernel loader -------------To get the kernel into memory different approaches can be used. Theydepend on what facilities are available:3.1) Writing the kernel onto a floppy using dd: As always you can just write the kernel onto a floppy using dd, but then it's not possible to use kernel command lines at all. To substitute the 'root=' parameter, create a dummy device on any linux system with major number 0 and minor number 255 using mknod: mknod /dev/boot255 c 0 255 Then copy the kernel zImage file onto a floppy using dd: dd if=/usr/src/linux/arch/i386/boot/zImage of=/dev/fd0 And finally use rdev to set the root device: rdev /dev/fd0 /dev/boot255 You can then remove the dummy device /dev/boot255 again. There is no real device available for it. The other two kernel command line parameters cannot be substi- tuted with rdev. Therefore, using this method the kernel will by default use RARP and/or BOOTP, and if it gets an answer via RARP will mount the directory /tftpboot/<client-ip>/ as its root. If it got a BOOTP answer the directory name in that answer is used.3.2) Using LILO When using LILO you can specify all necessary command line parameters with the 'append=' command in the LILO configuration file. However, to use the 'root=' command you also need to set up a dummy device as described in 3.1 above. For how to use LILO and its 'append=' command please refer to the LILO documentation.3.3) Using loadlin When you want to boot Linux from a DOS command prompt without having a local hard disk to mount as root, you can use loadlin. I was told that it works, but haven't used it myself yet. In general you should be able to create a kernel command line simi- lar to how LILO is doing it. Please refer to the loadlin docu- mentation for further information.3.4) Using a boot ROM This is probably the most elegant way of booting a diskless client. With a boot ROM the kernel gets loaded using the TFTP protocol. As far as I know, no commercial boot ROMs yet support booting Linux over the network, but there are two free implementations of a boot ROM available on sunsite.unc.edu and its mirrors. They are called 'netboot-nfs' and 'etherboot'. Both contain everything you need to boot a diskless Linux client.4.) Credits ------- The nfsroot code in the kernel and the RARP support have been written by Gero Kuhlmann <gero@gkminix.han.de>. The rest of the IP layer autoconfiguration code has been written by Martin Mares <mj@atrey.karlin.mff.cuni.cz>. In order to write the initial version of nfsroot I would like to thank Jens-Uwe Mager <jum@anubis.han.de> for his help.
