Getting Started Setting up an NFS server

Fundamental to Linux is the concept of a file system, i.e. an area where files are stored. Even when used in an embedded system, you will still need a file system. A file system can be stored on various media, for example a floppy or hard disk, RAM, Flash or ROM, and can also be accessed remotely across a network connection.

Linux supports several different file system organisations. These have different characteristics, which make them suitable for different applications. For example one may be faster than another, but be less efficient in how it uses the available storage space.

A file system is made available by mounting it. This makes the new file system visible as a directory in an existing file system. For most purposes crossing from one file system to another is invisible to user. File systems can be freely mixed, so for example an ext2 file system on a hard disk could be mounted into a JFFS2 file system in Flash.

However, the first file system is special. This is called the root file system, and is where the root directory (/) resides. This is mounted by the kernel as it boots, so the first program which the system executes (init) must be read from the root file system.

For development purposes, we find having the root file system as a remote file system, accessed across the network, the most convenient option. In this way we can make a directory, and all the files and directories contained in it, appear as the root file system on the target.

To do this we use a protocol called NFS (Network File System), and we need to set up a server on the PC to allow the target access to these files.

Preparing the root file system

A root file system will have been set up as part of the development kit's installation. The first thing you need to decide is whether to mount the installed root file system directly, or make a copy of it. Using the installed one directly has the advantage that you won't be taking up extra disk space with an extra copy.

However, if there will be multiple users all using the same host for development, it is useful to allow each of them to have their own root file system on the target. This will allow configuration files and start up scripts to be freely modified, and prevents one user accidentally interfering with another. In addition you cannot safely share a single root file system between multiple simultaneous targets (lock files and the generation of unique file names usually assume that only a single machine will be writing into the appropriate directories). Thus it may be useful for each user to have their own separate target root file system, keeping the original intact as a `reference' copy.

Making a copy of the root system must be done when logged in as root. The file system contains device special files (in /dev) which can only be created by root. The file system can be copied using:

host# cp --archive /opt/STM/ST40Linux-1.0/devkit/sh4/target /export/rootfs/user

The disadvantage of this is that every user of the system ends up with a complete copy of the root file system. This can amount to quite a large amount of data, most of which will never be modified. So if you have a large number of users sharing a single machine, it may be worth while investigating setting up the root file systems so most files are actually hard links back to the original binary, and only the files which are actually likely to be modified are copies.

For more information on setting up NFS root file systems, see the Network Boot HOWTO.

One thing you will need to remember is once you have made a copy of the file system, some of the standard tools for manipulating configuration files in the target file system can no longer be used. In particular this applies to sh4-linux-initdconfig and sh4-linux-shellconfig. This is because these tools will be unaware that you have made a copy of the file system, and so will still be operating on the files in the original target file system.

However, these tools are simply wrappers around a generic version of the tool, which uses an environment variable to determine where the root file system is. So by setting this environment variable and using the generic tool, it is possible to specify where the target file system is located, and allow these commands to work as expected. For example:

host# HHL_CROSS_TARGET_DIR=/export/rootfs/user/target
host# export HHL_CROSS_TARGET_DIR
host# target-initdconfig --list
...
host# target-shellconfig --list
...

Note that target-initdconfig is normally installed into /opt/STM/ST40Linux-1.0/host/bin, which you may not have on your PATH.

Setting up the NFS server

Depending on the options you choose when installing the Linux distribution, you may already have the NFS server installed and running. To check this simply log onto the Linux PC, and type:

host# chkconfig  --list portmap
host# chkconfig  --list nfs
host# chkconfig  --list nfslock

portmap         0:off   1:off   2:off   3:on    4:on    5:on    6:off

If you get an error message about No such file or directory then these packages are not installed. You will need to install the RPMs:

portmap-4.0-19
nfs-utils-0.1.9.1-1

(obviously the version numbers will depend on which distribution you are using). Consult the documentation which came with the Linux distribution for details on how to install RPMs.

Once the RPMS have been installed, repeat the chkconfig commands above. If the services are still listed as off for run levels 3, 4, and 5, then simply type:

host# chkconfig portmap on
host# chkconfig nfs on
host# chkconfig nfslock on

Next you need to tell the NFS server which file systems you want to make available to other machines. To do this you need to edit the file /etc/exports, creating it if it does not already exist. A line needs to be added which describes which directory should be exported, and with what permissions. This should look something like:

/opt/STM/ST40Linux-1.0/devkit/sh4/target *(rw,no_root_squash,async)

if the root file system has not been copied elsewhere. Replace the name of the root directory name with the root of the copied directory tree.

The last thing you need to check is whether you are running a firewall. Recent versions of many Linux distributions will install a firewall by default, and most of these will by default have a very conservative rule set. In general this is a good thing, as it will help to keep your PC secure if it is connected to the Internet. However, this will usually prevent the target connecting to your NFS server, as without additional configuration NFS cannot be considered secure.

Reconfiguring a firewall to permit the safe use of NFS is beyond the scope of these instructions. However, if you have additional security in place, for example being behind a corporate firewall, it is probably safe to disable the firewall completely.

Most Linux firewalls are based around ipchains or iptables. To check which, if any, of these are being used type:

host# chkconfig  --list ipchains
host# chkconfig  --list iptables

If you see a line which lists this service as being "on" in one or more run levels, you can disable it by typing, for example:

host# chkconfig  --del iptables

Finally reboot the PC to get the services started.