next up previous contents
Next: A quick note about Up: Configuration Previous: RAM* and LINK* syntax   Contents


Using a read-only root filesystem

Using a read-only root filesystem can be tricky at first. Many startup scripts and even some daemons expect to be able to write to the root filesystem, and fail if they cannot.

To solve these kinds of problems, carefully watch the console of a booting node for errors related to a 'Read-only file system'. When these kinds of errors occur, determine which file or directory was trying to be written to and include LINKDIR or LINKFILE directives in the configuration as appropriate.

As an example, several distributions like to write .pid files into /var/run to keep track of the process IDs of running daemons. At boot time, when these daemons try to start, there will be complaints about a 'Read-only file system' when /var/run is not writable. One solution for this problem is to add the following directive to the sysimage.conf file of the master image:

Don't forget to run mk-sysimage on the image after creating any LINK* directives. Now when the node boots, it will be able to write to /var/run, since the directory now effectively lives in /ram, the oneSIS RAM disk.

Giving a daemon the ability to write to a single file, such as /var/lib/random-seed, can be handled similarly. Rather than link all of /var/lib into the RAM disk, link just the needed file:

Again, don't forget to run mk-sysimage on the image. This file also has the -d flag so that the random-seed file is seeded instead of empty.

Closely watch the bootup and add any needed directives to the configuration to handle the idiosyncrasies of a read-only root filesystem. On a side note, it also helps to disable most of the unnecessary daemons enabled by default in many distributions.



Subsections
next up previous contents
Next: A quick note about Up: Configuration Previous: RAM* and LINK* syntax   Contents
root 2005-06-19