6.1.1.6. Major Number

Device character and block files possess a major number. The major number is used to communicate information to the device driver associated with the special file. For instance, under Linux the special files for SCSI disk drives should have a major number of 8, while the major number for an IDE disk drive's special file would be 3. As you can imagine, any change to a file's major number can have disastrous effects and is tracked by RPM.

6.1.1.7. Minor Number

A file's minor number is similar in concept to the major number, but conveys different information to the device driver. In the case of disk drives, this information can consist of a unit identifier. If the minor number changes, RPM will detect it.

6.1.1.8. Symbolic Link

If the file in question is really a symbolic link, the text string containing the name of the linked-to file is checked.

6.1.1.9. Modification Time

Most operating systems keep track of the date and time that a file was last modified. RPM uses this to its advantage by keeping modification times in its database.

6.2. When Verification Fails: rpm -V Output

When verifying a package, RPM produces output only if there is a verification failure. When a file fails verification, the format of the output is a bit cryptic, but it packs all the information you need into one line per file. Here is the format:

SM5DLUGT c file

In this syntax the following things are true:

• S is the file size.
• M is the file's mode.
• 5 is the MD5 checksum of the file.
• D is the file's major and minor numbers.
• L is the file's symbolic link contents.
• U is owner of the file.
• G is the file's group.

• T is the modification time of the file.
• c appears only if the file is a configuration file. This is handy for quickly identifying config files, as they are very likely to change, and therefore, very unlikely to verify successfully.
• file is the file that failed verification. The complete path is listed to make it easy to find.

It's unlikely that every file attribute will fail to verify, so each of the eight attribute flags will only appear if there is a problem. Otherwise, a . will be printed in that flag's place. Let's look at an example or two. In this case, the mode, MD5 checksum, and modification time for the specified file have failed to verify:

# rpm -V Xfree86

.M5....T /usr/X11R6/lib/X11/fonts/misc/fonts.dir

#

The file is not a config file (note the absence of a c between the attribute list and the filename).

In the following, the size, checksum, and modification time of the system password file have all changed:

# rpm -V setup

S.5....T c /etc/passwd

#

The c indicates that this is a config file.

This last example illustrates what RPM does when a file that should be there is missing entirely:

# rpm -V at

missing    /var/spool/at/spool

#

6.2.1. Other Verification Failure Messages

When rpm -V finds other problems, the output is a bit easier to understand:

# rpm -V blather

Unsatisfied dependencies for blather-7.9-1:    bother >= 3.1

#

It's pretty easy to see that the blather package requires at least version 3.1 of the bother package.

The output from a package's verification script is a bit harder to categorize because the script's contents, as well as its messages, are entirely up to the package builder.

6.3. Selecting What to Verify and How

There are several ways to verify packages installed on your system. If you've taken a look at RPM's query command, you'll find that many of them are similar. Let's start with the simplest method of specifying packages: the package label.

6.3.1. The Package Label: Verify an Installed Package Against the RPM Database

You can simply follow the rpm -V command with all or part of a package label. As with every other RPM command that accepts package labels, you'll need to carefully specify each part of the label you include. Keep in mind that package names are case sensitive, so rpm -V PackageName and rpm -V packagename are not the same. Let's verify the initscripts package:

# rpm -V initscripts

#

Although it looks like RPM didn't do anything, the following steps were performed:

1. For every file in the package, RPM checked the nine file attributes discussed earlier.
2. If the package was built with dependencies, the RPM database was searched to ensure that the packages that satisfy those dependencies were installed.
3. If the package was built with a verification script, that script was executed.

In our example, each of these steps was performed without error—the package verified successfully. Remember, with rpm -V you'll only see output if a package fails to verify.

6.3.2. -a: Verify All Installed Packages Against the RPM Database

If you add -a to rpm -V, you can easily verify every installed package on your system. It might take a while, but when it's done, you'll know exactly what's been changed on your system:

# rpm -Va

.M5....T     /usr/X11R6/lib/X11/fonts/misc/fonts.dir

missing      /var/spool/at/.lockfile

missing      /var/spool/at/spool

S.5....T     /usr/lib/rhs/glint/icon.pyc

..5....T  c  /etc/inittab

..5.....     /usr/bin/loadkeys

#

Don't be too surprised if rpm -Va turns up a surprising number of files that failed verification. RPM's verification process is very strict! In many cases, the changes flagged don't indicate problems—they are only an indication of your system's configuration being different from what