Библиотека сайта или "Мой Linux Documentation Project"
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
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
/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
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
/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.
/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
/etc/fstab file on any of the popular
/etc/mtab file presents a unique
challenge, because it does not contain static information like
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
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
read-only at startup. This creates a paradox. We cannot create an
mtab, because the
filesystem is not mounted as writable and we should not mount any
filesystems until we have created an empty
In order to sidestep this problem we need to do the following:
/as read-write, but use the
-noption so that mount does not attempt to write an entry to
/etc/mtabwhich is read-only at this point.
Create an empty
/etc/mtabfile now that the filesystem is writable.
/as read-write again, this time using the
-foption so that an entry is written into
/is not actually mounted a second time.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.