Booting with an NFS Root Filesystem

It is possible to boot most EMAC OE systems using NFS (Network File System) as the root filesystem. This method can be especially useful during development where the root filesystem is changing frequently. This can save time as well as wear on the on-board flash device. This page describes the steps required to boot over NFS.

Prerequisites

Some prerequisites must be met prior to being able to boot a root filesystem over NFS.

TFTP Server

A TFTP server is required if a kernel image is not already programmed in flash. For information on installing a TFTP server, see Installing TFTP server.

NFS Server

To boot an EMAC OE system over NFS, an NFS server must be available on the local network. This is often the same machine that is being used for software development. EMAC recommends using the nfs-kernel-server package available on most desktop Linux distributions if setting up a new NFS server. Once the server has been installed, export a directory to use as the root filesystem. This is often done using the /etc/exports file. This document assumes that the root filesystem for the board will be located at /srv/nfs/rootfs on the NFS server.

For more information on setting up an NFS server, see Setting up an NFS File Server.

Root Filesystem

A complete root filesystem for the EMAC OE system to boot from must be stored on the NFS server. The NFS server must be configured to allow clients to access this filesystem. The root filesystem does not have to be the directory shared by the NFS filesystem; it can be in a subdirectory, which means many root filesystems can be shared by one NFS server.

Configuring the Client to Boot from NFS

Configuring U-Boot

Set the bootargs variable to tell the kernel to boot into the NFS filesystem:

On initial use of U-boot the console variable should be set to the device's debug UART and buad rate, so kernel boot information can be displayed to the console. This is done as follows.

U-Boot> setenv console ttyXX 1152000
U-Boot> saveenv   

Where XX should be replaced by your devices default debug UART.

NOTE

On initial use of U-boot the console variable should be set to the device's debug UART and buad rate, so kernel boot information can be displayed to the console. This is done as follows. U-Boot> setenv console ttyXX 1152000 U-Boot> saveenv Where XX should be replaced by your devices default debug UART.

U-Boot> setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=dhcp nfsroot=10.0.0.20:/srv/nfs/test_fileystem
U-Boot> run bootargs

This line sets up the environment needed to boot from the NFS server. These options will be passed to the Linux kernel when booting it. The console=${console} part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of console=ttyS0,115200n8. The root=/dev/nfs directive tells Linux to instantiate with the virtual device, /dev/nfs, as the root filesystem. The rootfstype=nfs directive tells Linux that the root filesystem is of the NFS variety. The ip=dhcp directive tells Linux to acquire an IP address by requesting one from the DHCP server. The nfsroot=10.0.0.20:/srv/nfs/test_filesystem directive tells Linux to look for an NFS server at 10.0.0.20 and to mount the /srv/nfs/test_filesystem directory as the root filesystem for the machine.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the NFS root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

Alternate Kernel Load

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. Also see Executing kernel from RAM

U-Boot> set autoload no
U-Boot> dhcp
DHCP client bound to address 10.0.0.100

Here, the first command, set autoload no, tells U-Boot not to try to load an image after they've gotten an IP address from the DHCP server. The second command, dhcp, tells U-Boot to use DHCP to acquire an IP address. In this example, the DHCP server assigned 10.0.0.100 as the IP address for the machine.

U-Boot> set serverip 10.0.0.20

This line sets the IP address of the TFTP server to 10.0.0.20. This is the server which hosts the Linux kernel which will be used by the machine.

U-Boot> tftp ${loadaddr} zImage
...
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####################

This line tells U-Boot to load the kernel from the TFTP server, whose IP address was set earlier with the set serverip 10.0.0.20 command. The filename U-Boot requests from the TFTP server is zImage, and it stores it in the memory location pointed to by loadaddr. The text which follows displays U-Boot's progress in loading the kernel into RAM. When the U-Boot prompt returns, the environment is fully setup and ready to boot from an NFS root filesystem.

U-Boot> bootz ${loadaddr}

The bootz command tells U-Boot to boot the kernel from RAM. This means it boots the kernel which was just loaded into RAM, passing the commandline arguments specified by bootargs to the Linux kernel as it does so.

The machine should now boot, and show output on its console as it does so.

Conclusion

Using NFS for the root filesystem allows boards to boot quickly into test versions of a filesystem, provides a tool for remotely backing up the filesystem installed on an embedded machine, can provide a central filesystem image for many boards which can allow updating one filesystem to update all boards which use it simultaneously, and more. Setting up a machine to boot to a root filesystem via NFS requires little work; most of the work is in setting up the server.