We can use the Filesystem Hierarchy Standard (FHS) document to help find the names of utilities we need and where they reside in the directory structure. The FHS /sbin directory lists fsck and something called fsck.* for checking filesystems. Since we are using a Second Extended (ext2) filesystem the fsck.* becomes fsck.ext2 for our purposes. Mounting filesystems is done using the commands mount and umount in the /bin directory. However, the name of a script to automatically mount local filesystems cannot be found. On most systems this type of script is in the /etc directory, but while FHS does list requirements for /etc, it does not currently make recommendations for startup scripts. Several GNU/Linux distributions use /etc/init.d as the place to hold startup scripts so we will put our filesystem mounting script there.
In the previous chapter we used manpages to help us find source code. In this chapter we will use a tool called the Linux Software Map (LSM). LSM is a database of GNU/Linux software that tracks such things as package name, author, names of binaries that make up the package and download sites. Using an LSM search engine we can locate packages using command names as keywords.
If we search Ibiblio's Linux Software Map (LSM) at http://www.ibiblio.org/pub/Linux/ for the keyword "fsck" we get a large number of matches. Since we are using a Second Extended filesystem, called ext2 for short, we can refine the search using "ext2" as a keyword. Supplying both keywords to the LSM search engine comes up with a package called e2fsprogs. Looking at the LSM entry for e2fsprogs we find out that this package contains the utilities e2fsck, mke2fs, dumpe2fs, fsck and more. We also find out that the LSM entry for e2fsprogs has not been updated for a while. There is almost certainly a newer version out there somewhere. Another good Internet resource for source code is SourceForge at http://sourceforge.net/. Using the keyword "e2fsprogs" in the SourceForge search engine results in a much newer version of e2fsprogs.
Finding fsck was quite an adventure, but now we can move on to finding mount and umount. A search on LSM comes up with a number of matches, but most of them point to various versions of a package called util-linux. All we have to do is scroll through and pick the most recent release. The LSM entry for util-linux lists a lot of utilities besides just mount and umount. We should definitely scan through the list to see if any of the other util-linux commands show up in the FHS requirements for /bin and /sbin.
Below is a list of packages we have gathered so far and the utilities that match up with FHS.
e2fsprogs -- fsck, fsck.ext2 (e2fsck), mkfs.ext2 (mke2fs)
util-linux -- dmesg, getty (agetty), kill, login, mount, swapon, umount
Now that we have fsck and mount commands we need to come up with a shell script to automate checking and mounting the local filesystems. An easy way to do this would be to write a short, two line script that calls fsck and then mount. But, what if the filesystems are not clean? The system should definitely not try to mount a corrupted filesystem. Therefore we need to devise a way of determining the status of the filesystems before mounting them. The manpage for fsck gives some insight into how this can be accomplished using return codes. Basically, if fsck returns a code of zero or one it means the filesystem is okay and a return code of two or greater means some kind of manual intervention is needed. A simple if-then statement could evaluate the fsck return code to determine whether or not the filesystem should be mounted. For help on writing shell scripts we can turn to the BASH(1) manpage and the Advanced-BASH-Scripting-Guide. Both references are freely available from the Linux Documentation Project web site at http://www.tldp.org/.
The last thing to do is to figure out if any other files besides the binaries are needed. We learned about using ldd to check for library dependencies in the last phase of the project and we will use it to check the utilities in this phase too. There are also some other files that fsck and mount will need and the fsck(8) and mount(8) manpages give some insight into what those files are. There is /etc/fstab that lists devices and their mount points, /etc/mtab that keeps track of what is mounted, and a number of /dev files that represent the various disks. We will need to include all of these to have everything work right.
The /etc/fstab file is just a simple text file that can be created with any editor. We will need an entry for the root filesystem and for the proc filesystem. Information about the format of this file can be found in the fstab(5) manpage or by looking at the /etc/fstab file on any of the popular GNU/Linux distributions.
The /etc/mtab file presents a unique challenge, because it does not contain static information like fstab. The mtab file tracks mounted filesystems and therefore its contents change from time to time. We are particularly interested in the state of mtab when the system first starts up, before any filesystems are mounted. At this point /etc/mtab should be empty so we will need to configure a startup script to create an empty /etc/mtab before any filesystems are mounted. But it is not possible to create any files in the /etc directory because / is read-only at startup. This creates a paradox. We cannot create an empty mtab, because the / filesystem is not mounted as writable and we should not mount any filesystems until we have created an empty mtab. In order to sidestep this problem we need to do the following:
Remount / as read-write, but use the -n option so that mount does not attempt to write an entry to /etc/mtab which is read-only at this point.
Create an empty /etc/mtab file now that the filesystem is writable.
Remount / as read-write again, this time using the -f option so that an entry is written into /etc/mtab, but / is not actually mounted a second time.