You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
266 lines
9.4 KiB
266 lines
9.4 KiB
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>
|
|
Updated 2006 by Nico Schottelius <nico-kernel-nfsroot@schottelius.org>
|
|
Updated 2006 by Horms <horms@verge.net.au>
|
|
|
|
|
|
|
|
In order to use a diskless system, such as an X-terminal or printer server
|
|
for example, it is necessary for the root filesystem to be present on a
|
|
non-disk device. This may be an initramfs (see Documentation/filesystems/
|
|
ramfs-rootfs-initramfs.txt), a ramdisk (see Documentation/initrd.txt) or a
|
|
filesystem mounted via NFS. The following text describes on how to use NFS
|
|
for the root filesystem. For the rest of this text 'client' means the
|
|
diskless system, and 'server' means the NFS server.
|
|
|
|
|
|
|
|
|
|
1.) Enabling nfsroot capabilities
|
|
-----------------------------
|
|
|
|
In order to use nfsroot, NFS client support needs to be selected as
|
|
built-in during configuration. Once this has been selected, the nfsroot
|
|
option will become available, which should also be selected.
|
|
|
|
In the networking options, kernel level autoconfiguration can be selected,
|
|
along with the types of autoconfiguration to support. Selecting all of
|
|
DHCP, BOOTP and RARP is safe.
|
|
|
|
|
|
|
|
|
|
2.) Kernel command line
|
|
-------------------
|
|
|
|
When the kernel has been loaded by a boot loader (see below) it needs to be
|
|
told what root fs device to use. And in the case of nfsroot, where to find
|
|
both the server and the name of the directory on the server to mount as root.
|
|
This can be established using the following 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.
|
|
The default address is determined by the `ip' parameter
|
|
(see below). This parameter allows the use of different
|
|
servers for IP autoconfiguration and NFS.
|
|
|
|
<root-dir> Name of the directory on the server to mount as root.
|
|
If there is a "%s" token in the string, it will be
|
|
replaced by the ASCII-representation of the client's
|
|
IP address.
|
|
|
|
<nfs-options> Standard NFS options. All options are separated by commas.
|
|
The following defaults are 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, ac
|
|
|
|
|
|
ip=<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
|
|
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.
|
|
|
|
<client-ip> IP address of the client.
|
|
|
|
Default: Determined using autoconfiguration.
|
|
|
|
<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.
|
|
|
|
Only required for for NFS root. That is autoconfiguration
|
|
will not be triggered if it is missing and NFS root is not
|
|
in operation.
|
|
|
|
Default: Determined using autoconfiguration.
|
|
The address of the autoconfiguration server is used.
|
|
|
|
<gw-ip> IP address of a gateway if the server is on a different subnet.
|
|
|
|
Default: Determined using autoconfiguration.
|
|
|
|
<netmask> Netmask for local network interface. If unspecified
|
|
the netmask is derived from the client IP address assuming
|
|
classful addressing.
|
|
|
|
Default: Determined using autoconfiguration.
|
|
|
|
<hostname> Name of the client. May be supplied by autoconfiguration,
|
|
but its absence will not trigger autoconfiguration.
|
|
|
|
Default: Client IP address is used in ASCII notation.
|
|
|
|
<device> Name of network device to use.
|
|
|
|
Default: If the host only has one device, it is used.
|
|
Otherwise the device is determined using
|
|
autoconfiguration. This is done by sending
|
|
autoconfiguration requests out of all devices,
|
|
and using the device that received the first reply.
|
|
|
|
<autoconf> Method to use for autoconfiguration. In the case of options
|
|
which specify multiple autoconfiguration protocols,
|
|
requests are sent using all protocols, and the first one
|
|
to reply is used.
|
|
|
|
Only autoconfiguration protocols that have been compiled
|
|
into the kernel will be used, regardless of the value of
|
|
this option.
|
|
|
|
off or none: don't use autoconfiguration (default)
|
|
on or any: use any protocol available in the kernel
|
|
dhcp: use DHCP
|
|
bootp: use BOOTP
|
|
rarp: use RARP
|
|
both: use both BOOTP and RARP but not DHCP
|
|
(old option kept for backwards compatibility)
|
|
|
|
Default: any
|
|
|
|
|
|
|
|
|
|
3.) Boot Loader
|
|
----------
|
|
|
|
To get the kernel into memory different approaches can be used.
|
|
They depend on various facilities being available:
|
|
|
|
|
|
3.1) Booting from a floppy using syslinux
|
|
|
|
When building kernels, an easy way to create a boot floppy that uses
|
|
syslinux is to use the zdisk or bzdisk make targets which use
|
|
and bzimage images respectively. Both targets accept the
|
|
FDARGS parameter which can be used to set the kernel command line.
|
|
|
|
e.g.
|
|
make bzdisk FDARGS="root=/dev/nfs"
|
|
|
|
Note that the user running this command will need to have
|
|
access to the floppy drive device, /dev/fd0
|
|
|
|
For more information on syslinux, including how to create bootdisks
|
|
for prebuilt kernels, see http://syslinux.zytor.com/
|
|
|
|
N.B: Previously it was possible to write a kernel directly to
|
|
a floppy using dd, configure the boot device using rdev, and
|
|
boot using the resulting floppy. Linux no longer supports this
|
|
method of booting.
|
|
|
|
3.2) Booting from a cdrom using isolinux
|
|
|
|
When building kernels, an easy way to create a bootable cdrom that
|
|
uses isolinux is to use the isoimage target which uses a bzimage
|
|
image. Like zdisk and bzdisk, this target accepts the FDARGS
|
|
parameter which can be used to set the kernel command line.
|
|
|
|
e.g.
|
|
make isoimage FDARGS="root=/dev/nfs"
|
|
|
|
The resulting iso image will be arch/<ARCH>/boot/image.iso
|
|
This can be written to a cdrom using a variety of tools including
|
|
cdrecord.
|
|
|
|
e.g.
|
|
cdrecord dev=ATAPI:1,0,0 arch/i386/boot/image.iso
|
|
|
|
For more information on isolinux, including how to create bootdisks
|
|
for prebuilt kernels, see http://syslinux.zytor.com/
|
|
|
|
3.2) Using LILO
|
|
When using LILO all the necessary command line parameters may be
|
|
specified using the 'append=' directive in the LILO configuration
|
|
file.
|
|
|
|
However, to use the 'root=' directive you also need to create
|
|
a dummy root device, which may be removed after LILO is run.
|
|
|
|
mknod /dev/boot255 c 0 255
|
|
|
|
For information on configuring LILO, please refer to its documentation.
|
|
|
|
3.3) Using GRUB
|
|
When using GRUB, kernel parameter are simply appended after the kernel
|
|
specification: kernel <kernel> <parameters>
|
|
|
|
3.4) Using loadlin
|
|
loadlin may be used to boot Linux from a DOS command prompt without
|
|
requiring a local hard disk to mount as root. This has not been
|
|
thoroughly tested by the authors of this document, but in general
|
|
it should be possible configure the kernel command line similarly
|
|
to the configuration of LILO.
|
|
|
|
Please refer to the loadlin documentation for further information.
|
|
|
|
3.5) Using a boot ROM
|
|
This is probably the most elegant way of booting a diskless client.
|
|
With a boot ROM the kernel is loaded using the TFTP protocol. The
|
|
authors of this document are not aware of any no commercial boot
|
|
ROMs that support booting Linux over the network. However, there
|
|
are two free implementations of a boot ROM, netboot-nfs and
|
|
etherboot, both of which are available on sunsite.unc.edu, and both
|
|
of which contain everything you need to boot a diskless Linux client.
|
|
|
|
3.6) Using pxelinux
|
|
Pxelinux may be used to boot linux using the PXE boot loader
|
|
which is present on many modern network cards.
|
|
|
|
When using pxelinux, the kernel image is specified using
|
|
"kernel <relative-path-below /tftpboot>". The nfsroot parameters
|
|
are passed to the kernel by adding them to the "append" line.
|
|
It is common to use serial console in conjunction with pxeliunx,
|
|
see Documentation/serial-console.txt for more information.
|
|
|
|
For more information on isolinux, including how to create bootdisks
|
|
for prebuilt kernels, see http://syslinux.zytor.com/
|
|
|
|
|
|
|
|
|
|
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.
|
|
|