Difference between revisions of "Booting with an NFS Root Filesystem"

From wiki.emacinc.com
Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{todo|SEOKWREV; (12.18.13-22:30->MD+);(12.19.13-13:20->MD+);(12.19.13-17:00->KY+);(01.03.14-13:10->MW+);(03.06.14-15:15->BS-);(04.11.14-14:05->BS+)|Mike Dean|project=oe 4,oe 5,md,SEOKWREV,ky,mw,bs}}
 
 
 
{{#seo:
 
{{#seo:
 
|title=Booting with an NFS Root Filesystem
 
|title=Booting with an NFS Root Filesystem
Line 17: Line 15:
 
===TFTP Server===
 
===TFTP Server===
  
A TFTP server is required to host the kernel image.  For information on installing a TFTP server, see [[Installing 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===
 
===NFS Server===
Line 31: Line 29:
 
==Configuring the Client to Boot from NFS==
 
==Configuring the Client to Boot from NFS==
  
The method used to configure a client to boot with an NFS mounted root filesystem depends on the type of bootloader the machine uses.  Configuring U-Boot <!-- and LILO --> for booting over NFS is covered here.
+
===Configuring U-Boot===
<!--
+
 
Most ARM-based systems use U-Boot as the bootloader. For ARM machines, start with the U-Boot section. Most x86 machines, on the other hand, use LILO as the bootloader; for such a machine, start with the LILO section.
+
Set the bootargs variable to tell the kernel to boot into the NFS filesystem:
-->
+
 
 +
{{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.   |}}
  
===Configuring U-Boot===
+
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 <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>.  The <code>root=/dev/nfs</code> directive tells Linux to instantiate with the virtual device, <code>/dev/nfs</code>, as the root filesystem.  The <code>rootfstype=nfs</code> directive tells Linux that the root filesystem is of the NFS variety.  The <code>ip=dhcp</code> directive tells Linux to acquire an IP address by requesting one from the DHCP server.  The <code>nfsroot=10.0.0.20:/srv/nfs/test_filesystem</code> directive tells Linux to look for an NFS server at <code>10.0.0.20</code> and to mount the <code>/srv/nfs/test_filesystem</code> 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===
  
A series of U-Boot commands are used to tell U-Boot to boot an NFS filesystem:
+
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 [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM  | Executing kernel from RAM ]]
  
 
  U-Boot> set autoload no
 
  U-Boot> set autoload no
Line 50: Line 64:
 
This line sets the IP address of the TFTP server to <code>10.0.0.20</code>.  This is the server which hosts the Linux kernel which will be used by the machine.
 
This line sets the IP address of the TFTP server to <code>10.0.0.20</code>.  This is the server which hosts the Linux kernel which will be used by the machine.
  
U-Boot> setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=dhcp nfsroot=10.0.0.20:/srv/nfs/test_fileystem
+
  U-Boot> tftp ${loadaddr} zImage
 
 
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 <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>.  The <code>root=/dev/nfs</code> directive tells Linux to instantiate with the virtual device, <code>/dev/nfs</code>, as the root filesystem.  The <code>rootfstype=nfs</code> directive tells Linux that the root filesystem is of the NFS variety.  The <code>ip=dhcp</code> directive tells Linux to acquire an IP address by requesting one from the DHCP server.  The <code>nfsroot=10.0.0.20:/srv/nfs/test_filesystem</code> directive tells Linux to look for an NFS server at <code>10.0.0.20</code> and to mount the <code>/srv/nfs/test_filesystem</code> directory as the root filesystem for the machine.
 
 
 
  U-Boot> tftp ${loadaddr} uImage
 
 
  ...
 
  ...
 
  Loading: #################################################################
 
  Loading: #################################################################
Line 67: Line 77:
 
           #####################
 
           #####################
  
This line tells U-Boot to load the kernel from the TFTP server, whose IP address was set earlier with the <code>set serverip 10.0.0.20</code> command.  The filename U-Boot requests from the TFTP server is <code>uImage</code>, and it stores it in the memory location pointed to by <code>loadaddr</code>.  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.
+
This line tells U-Boot to load the kernel from the TFTP server, whose IP address was set earlier with the <code>set serverip 10.0.0.20</code> command.  The filename U-Boot requests from the TFTP server is <code>zImage</code>, and it stores it in the memory location pointed to by <code>loadaddr</code>.  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> bootm ${loadaddr}
+
  U-Boot> bootz ${loadaddr}
  
The <code>bootm</code> command tells U-Boot to boot from RAM.  This means it boots the kernel which was just loaded into RAM, passing the commandline arguments specified by <code>bootargs</code> to the Linux kernel as it does so.
+
The <code>bootz</code> 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 <code>bootargs</code> to the Linux kernel as it does so.
  
 
The machine should now boot, and show output on its console as it does so.
 
The machine should now boot, and show output on its console as it does so.
 
<!--NOTE: It may be a good idea to tell the reader how to save this configuration to the environment so that it will automatically boot this way every time.  We can do this on demand, though. -->
 
<!--
 
===Configuring LILO===
 
 
For embedded machines which use LILO rather than U-Boot, the procedure for booting the machine with an NFS root filesystem is different.
 
 
'''TODO'''
 
-->
 
  
 
==Conclusion==
 
==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.  The ability to boot a root filesystem over NFS provides a powerful tool for many applications.
+
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.

Latest revision as of 14:42, 20 December 2019

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:



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.