next up previous contents
Next: Setting up variant system Up: Using a read-only root Previous: Using a read-only root   Contents


A quick note about /etc/mtab

Some operations do not behave well in a read-only environment. The way in which the mount program creates a lockfile for /etc/mtab is a prime example: when mount attempts to write to /etc/mtab, a lockfile is created as /etc/mtab.pid, where pid is the process ID of the process requesting the lock. This process prohibits a LINKFILE directive for /etc/mtab from having a writeable /etc/mtab live in the RAM disk, since mount still tries to create lock files in the read-only /etc and fails.

oneSIS gets around this problem by automatically converting /etc/mtab to be a symbolic link to /proc/mounts. The only negative effect is that userspace tools such as losetup and mount -o loop do not append entries to /proc/mounts, so mounted loopback filesystems do not appear to the system to be mounted. The result is that loopback filesystems can be mounted and unmounted, but the umount command does not automatically free the loopback device.

Usually a total of eight loopback filesystems can be mounted and unmounted before mount complains: `mount: could not find any free loop device'. The solution then is to manually detach the device associated with each loop device with losetup -d /dev/loop0; losetup -d /dev/loop1; ....

Alternatively, when /etc is deployed on a local disk, and auto-mounted read-write from an initrd, oneSIS automatically creates a real /etc/mtab to eliminate the problem with loopback mounts. If the local /etc is ever mounted read-only again, /etc/mtab is again converted to be a symlink to /proc/mounts.

Note: This swapping to and from a real /etc/mtab only occurs on locally deployed /etc directories. The /etc/mtab of the master image is always a symlink to /proc/mounts.


next up previous contents
Next: Setting up variant system Up: Using a read-only root Previous: Using a read-only root   Contents
root 2005-06-19