Linux+: Applications 07 – Yum Troubleshooting and Maintenance

J

Jarret W. Buse

Guest
Linux+: Applications 07 – Yum Troubleshooting and Maintenance

Troubleshooting and maintaining “yum” and the RPM database can be very important. Troubleshooting and maintaining “yum” and the RPM database does not have many subcommands for “yum”. The subcommands can be very important to keeping your Red Hat distro running smoothly.

To start, let's look at what the RPM database is to the Operating System (OS). The RPM Database holds all the information of every package installed with RPM. This, of course, includes any installations by “yum” since it works through RPM. The RPM database is usually located in the “/var/lib/rpm” folder.

If the RPM Database becomes corrupted, then the system will have a problem when using “yum” anytime the RPM database is accessed. The database can be corrupted and report incorrect information if anything is returned when the database is accessed.

To check the database for errors or any type of inconsistency, use the “check” subcommand. The syntax is:

yum check

If the RPM database has no errors, the output should be “check all”. With no extra subcommands, the default is to check “all” of the RPM database.

The various extra subcommands are:

  • all – all of the database is checked (default)
  • dependencies – checks only the package dependencies
  • duplicates – checks for duplicate installed packages of same version
  • obsoletes – check for obsolete packages
  • provides – check the provides portion of the database

For example, to check the dependencies on a Red Hat system,the command would be “yum check dependencies”. Any errors listed will be for dependency issues in the RPM Database.

Another issue with “yum” and RPM is that when packages are installed or upgraded, the files are stored in the cache. The cache can accumulate a lot of files in a short time. If a downloaded package is corrupted, then it needs to be deleted and downloaded again before it is installed. The cached files are usually stored in “/var/cache/yum”. Here, a directory is created for each repository and then the files from that repository are stored in the folder. In the “yum.conf” file, a setting called “keepcache” is used to determine if the cache is cleared after a package installation. If the value is set to “0” then the cache is cleared while a “1” is used to keep the cache.

To clear the cache manually, use the subcommand “clean” in the syntax of:

yum clean

As with the “check” subcommand, there are extra subcommands used with “clean”. The options are:

  • expire-cache – removes the local data saying when the information was downloaded for each repository. When the repository cache is used, it will need to be validated and updated again
  • packages – deletes any cached packages from the system
  • headers – clears out the header files, which is used for dependency resolution
  • metadata – removes the files which yum uses for determining remote availability of packages. By clearing the information, yum must download all the metadata the next time it runs
  • dbcache – deletes the sqlite cache used for metadata access. This makes “yum” download the sqlite metadata the next time it is run
  • rpmdb – clears cached data from the local RPM Database
  • plugins – eliminates cached data of enabled plugins
  • all – removes all of the above data
The “fs” subcommand is used to handle specific filesystem data. There are extra subcommands as follows:

  • filters – lists filesystem filters which are enabled
  • filter languages en:es – filters installed languages
  • filter documentation – filters documents being installed
  • refilter [package(s)] – reinstall specified packages with the new “fs” settings taking effect
  • refilter-cleanup [package(s)] – removes specified packages with the new “fs” settings taking effect
  • du [path] – lists the disk usage for the specified folder for both the top 4 packages and the top 4 non-packages
  • status [path] – shows the status of the files if any have changed
  • diff [path] – shows the difference of the files and those in /tmp

NOTE: The “fs” subcommands require root priveleges.

The “fssnapshot” is used to create a snapshot of the LVM data.

NOTE: The “fssnapshot” command requires the installation of the “python-lvm” package.

There are a few subcommands for fssnapshot:

  • list – lists snapshots taken
  • have-space – determines if space is available to create a snapshot
  • (fssnap) create – creates a snapshot
  • (fssnap) delete <device> - deletes a snapshot

This command has a few sub-commands to act on the LVM data of the host, to list snapshots and then create and remove them. The simplest is the command “yum fssnapshot” which shows a snapshot summary.

The “list” subcommand lists snapshots which have been created.

One very important subcommand is “have-space”. This subcommand can determine if there is space to save a snapshot. If enough space is not available, then a snapshot will not be created.

The command “yum fssnap create” is used to create a new snapshot. The command “yum fssnap delete <device>” is used to delete the specified snapshot.

The “history” subcommand allows you to see previous transactions. To see previous transactions, the “history_record.config” option should be set to enable a history to be kept.

The “history” subcommand also has subcommands which follow:

  • list – lists transaction history
  • info <id> – gives information on specific transaction
  • packages-list <package_name> – lists packages in history retrieved from info subcommand
  • packages-info <package_name> – information on specific package from package-list
  • summary – summary listing of installs and updates
  • undo <id> - removes a transaction
  • redo <id> - re-installs a transaction
  • rollback <id> - rollback all transactions to point <id>
  • new - starts a new history file

When you perform a “yum history list” command, you get a listing of the transaction history. Each transaction includes the transaction id, logged in user, date and time, actions and altered information. When using any command requiring the transaction id, the id is found in the history list.

The “info” subcommand gives more specific data about the transaction by specifying the transaction id.

Within the details from the “info” command, the package name is listed which was installed. This package_name can be used for the “package-list” subcommand to list the package.

The package_name can also be used for the “package-info” subcommand to get more detailed information on the package.

The “summary” gives a summary of the installs and updates performed.

With the transaction id, a transaction can be undone or removed with the “undo” subcommand.

A transaction can be re-performed with the “redo” subcommand.

The “rollback” causes all transactions to be undone starting with the most recent to the one specified (but not including it). For example, if the history shows 20 transactions, the command “yum history rollback 8” will remove all transactions from 20 down to 9. Transactions 1 to 8 will remain intact.

The “new” subcommand allows a new history file to be started, erasing the old one.

These commands need to be practiced to be sure they are thoroughly understood.
 

Attachments

  • slide.jpg
    slide.jpg
    32.9 KB · Views: 156,187

Members online


Top