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
•
5.2.3. Automating fsck and mount
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/.
5.2.4. File dependencies
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.
5.2.4.1. /etc/fstab
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.
Pocket Linux Guide
Chapter 5. Checking and Mounting Disks
22
