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.