Section 7.4. I Can t Boot Because of Some

7.4. I Can't Boot Because of Some "File Not Found" Error

Closely related to the kernel panic is a "File not found" error that stops the boot process. While not as severe as a kernel panic, it is still a fatal error that prevents booting into Linux. As with panics, the primary causes of "File not found" messages are errors in files related to the boot process. And the error messages are relatively straightforward, so you can usually figure out how to specify the proper filename and directory.

One example of a "File not found" error is the following, where the root(hd0,0) directive points to the wrong partition. It's pretty clear what the problem is in this case, because the filesystem is listed as FAT:

 root (hd0,0)  Filesystem type is fat, partition type 0xb kernel /vmlinuz-2.4.21-15.EL ro root=LABEL=/ hdd=ide-scsi Error 15: File not found 

The noted partition is (hd0,0), also known as /dev/hda1. It's formatted to the FAT filesystem. Your Linux boot files are almost certainly not located on a partition formatted to a Microsoft filesystem. You may need to do some searching to find the partition with your Linux boot files. Then you can revise your bootloader to point to the right partition.

In the following case, the problem is less clear. While the message is almost identical to the previous error, the problem is actually a missing Linux kernel:

 root (hd0,0)  Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.4.21-15.EL ro root=LABEL=/ hdd=ide-scsi Error 15: File not found 

The solution may be as simple as correcting a typo in the name of the file you specified as the kernel.

The following error message illustrates a boot process that proceeded a bit further. As the messages stop at the Initial RAM disk message, you might (correctly) conclude that the problem is related to a missing, mislinked, or misnamed Initial RAM disk file:

 root (hd0,0)  Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.4.21-15.EL ro root=LABEL=/ hdd=ide-scsi  [Linux-bzImage, setup=0x1400, size=0x12dae6] initrd /initrd-2.4.21-15.EL.img Error 15: File not found 

The following error message says that Linux can't find /etc/inittab:

 INIT: No inittab file found 

Another error message indicates that the /boot filesystem is mislabeled:

 Couldn't find matching filesystem: LABEL=/bot 

A closely related error may indicate that the runlevel field has been omitted or incorrectly specified in the id directive in /etc/inittab:

 INIT: /etc/inittab[20]: fault unknown action field Enter runlevel: 

At the prompt just shown, if you can enter the number associated with your preferred runlevel, there may be a problem with the id directive in /etc/inittab. Otherwise, there may be a different problem with the /etc/inittab file.

7.4.1. Finding That File

If you see a "File not found" message, focus on the filename associated with the message. Usually, a file or directory specified in /etc/inittab or /etc/fstab is the source of the problem. A Linux guru should know these files wellor at least be able to refer to them on other Linux computers as models.

Commands related to those files include mount and init. If either of those commands is corrupted, or perhaps replaced by a cracker, you'll see characteristic symptoms. A missing /sbin/init leads right to a command shell prompt such as:

 sh-3.00# 

A missing mount command, on the other hand, leads to unexpected errors. In SUSE, you'll see a number of "failed to mount" errors. In Red Hat, you'll see something simpler:

 Is /proc mounted? 

With Red Hat and SUSE, you can see whether one of these files became corrupted by checking it against the associated RPM:

 rpm -Vf /bin/mount 

If you don't see any output, the file is verified as the original. Otherwise, you may have a problem, depending on the output. The options you might see are shown in Table 7-1.

Table 7-1. rpm output for files that are unverified

Output	Description
S	Mismatched file size
M	Different permissions or file type (Mode)
5	Incorrect MD5 checksum
L	Bad symbolic link
D	Wrong device number
U	Ownership (user) wrong
G	Ownership (group) wrong
T	Mismatched file modification time
c	Identifies a configuration file

If you're checking files on Debian-based packages, use the debsums command. It uses the MD5 checksum for each file to verify its authenticity. This requires you to get the Debian package from a CD or download. I've downloaded and installed my Debian packages with the apt-get command, and they're stored in the /var/cache/apt/archives directory. Thus, if I wanted to check the MD5 checksums of the files from the smbclient package, I'd run the following command:

 debsums -ag /var/cache/apt/archives/smbclient* 

Any MD5 checksum for a specific file that does not match returns a message such as:

 usr/bin/smbtar                 FAILED 

For a more comprehensive and preemptive approach to detecting the malicious replacement of critical system files, install Tripwire on your system as soon as you install the operating system (and before connecting to a network). Tripwire works on most modern Linux distributions. For more information on the open source version of this tool, refer to http://www.tripwire.org.