Loading...

VONDS ©

Lab 122: RPM Package Management

Back to Lab Index

Use rpm directly to query installed packages and file ownership, verify package integrity, validate a local RPM, and perform controlled local install/remove workflows. Finish by rebuilding the RPM database as a recovery step when state is inconsistent.

packages rpm verification rhel

Scenario

You are working on an RPM-based system where you need low-level package visibility and repair options without relying on higher-level workflows. Your goal is to use rpm to query what’s installed, validate ownership of files, verify package integrity, confirm signatures on a local RPM, install or upgrade it, remove it cleanly, and perform basic database maintenance.

Operator context

In production, rpm is your source of truth for “what owns this file,” “was this package modified,” and “is this RPM trustworthy.” Use it to validate state before changes and to confirm repairs after.

Objective

  • List installed RPM packages (quick inventory).
  • Inspect installed package metadata with rpm -qi .
  • List files installed by a package with rpm -ql .
  • Resolve file ownership with rpm -qf .
  • Verify package integrity with rpm -V .
  • Validate signature and digests on a local RPM with rpm -K .
  • Query metadata from an uninstalled RPM with rpm -qp --info .
  • Install or upgrade a local RPM with rpm -Uvh .
  • Remove a package with rpm -e .
  • Rebuild the RPM database with rpm --rebuilddb .

Concepts

  • RPM database queries are local truth for installed package state ( rpm -qa , rpm -qi ).
  • File ownership and provenance is an RPM workflow ( rpm -qf ) and is a core troubleshooting primitive.
  • Verification checks detect drift from packaged state ( rpm -V ) and help triage suspected tampering or corruption.
  • Signature and digest checks validate trust before local installation ( rpm -K ).
  • Local file installation is controlled and explicit ( rpm -Uvh ) and should be used when repos are unavailable or when you need an exact build.
  • Database rebuild is a recovery operation ( rpm --rebuilddb ), not a routine step.

Walkthrough

Step 1 : List the first 10 installed RPM packages.
Command 
rpm -qa | head -n 10

This gives you a fast inventory sample and confirms the RPM database is readable. 

bash-5.1.8-3.el9.x86_64
coreutils-8.32-34.el9.x86_64
filesystem-3.16-2.el9.x86_64
glibc-2.34-100.el9.x86_64
grep-3.6-5.el9.x86_64
gzip-1.10-6.el9.x86_64
rpm-4.16.1.3-31.el9.x86_64
shadow-utils-4.9-8.el9.x86_64
vim-minimal-8.2.2637-20.el9.x86_64
which-2.21-29.el9.x86_64
Step 2 : Show installed package info for bash .
Command 
rpm -qi bash

Use this when you need install-time context, summary, architecture, and release metadata. 

Name        : bash
Version     : 5.1.8
Release     : 3.el9
Architecture: x86_64
Summary     : The GNU Bourne Again shell
License     : GPLv3+
Step 3 : List files installed by bash .
Command 
rpm -ql bash

This helps when you need to confirm expected files exist or identify what should exist. 

/bin/bash
/etc/skel/.bashrc
/usr/share/man/man1/bash.1.gz
Step 4 : Identify which package owns /bin/bash .
Command 
rpm -qf /bin/bash

This is the file-ownership lookup you use during troubleshooting and cleanup. 

bash-5.1.8-3.el9.x86_64
Step 5 : Verify integrity of installed bash .
Command 
rpm -V bash

Verification reports unexpected changes. Clean output usually means no differences from packaged state, excluding expected config behavior.

What to look for

Output lines indicate mismatches (size, permissions, checksum, mtime, etc.). Config files may legitimately differ depending on environment and policy.

Step 6 : Validate signature and digests of a local RPM.
Safety note

Do not install RPMs from unknown sources. If digests or signatures fail, stop and validate the origin and transport path.

Command 
rpm -K htop-3.3.0-1.el9.x86_64.rpm

This is a trust check before installation. You want clean digests and a valid signature status. 

htop-3.3.0-1.el9.x86_64.rpm: digests signatures OK
Step 7 : Query metadata from a local RPM (not installed).
Command 
rpm -qp --info htop-3.3.0-1.el9.x86_64.rpm

Use this to confirm name, version, and architecture before you install a local file. 

Name        : htop
Version     : 3.3.0
Release     : 1.el9
Architecture: x86_64
Summary     : Interactive process viewer
Step 8 : Install or upgrade the local RPM with progress output.
Command 
sudo rpm -Uvh htop-3.3.0-1.el9.x86_64.rpm

-U upgrades or installs, -v increases detail, and -h prints a progress bar. Use this for controlled local installs outside of repo workflows. 

Preparing...                          ################################# [100%]
Updating / installing...
   1:htop-3.3.0-1.el9                 ################################# [100%]
Step 9 : Remove the htop package.
Command 
sudo rpm -e htop

This erases files owned by the package and removes it from the RPM database. Dependency checks may block removal. 

Preparing packages...
Erasing     : htop-3.3.0-1.el9.x86_64
Verifying   : htop-3.3.0-1.el9.x86_64
Step 10 : Rebuild the RPM database (maintenance).
Command 
sudo rpm --rebuilddb

This is a repair step when the RPM database becomes inconsistent or corrupted. Treat it as a recovery operation, not a routine action. 

Rebuilding RPM database...
Done.

Common breakpoints

rpm -V reports unexpected differences

Drift is not always compromise. Compare against known policy, and pay attention to config files and expected admin changes. Use the output as a triage signal, then validate the specific files.

rpm -K reports NOT OK

Do not install the RPM. Validate the source, re-download over a trusted path, and confirm you are checking the correct file. Treat failed checks as an integrity incident until proven otherwise.

rpm -e fails due to dependencies

The package is required by something else. Identify dependents before removal, or use a higher-level workflow that can resolve dependency changes safely.

rpm --rebuilddb takes a long time or errors

This can indicate filesystem problems or a damaged database directory. Confirm disk health and available space, then retry. If the database is severely corrupted, recovery may require backups or vendor guidance.

Cleanup checklist

If you installed a local test RPM, remove it and confirm package state is clean. If you rebuilt the database as part of recovery, verify RPM queries still work normally.

Commands 
rpm -q htop || true
sudo rpm -e htop || true
rpm -qa | head -n 5
Success signal

The test package is absent (if installed), and RPM queries complete without database errors.

Reference

  • rpm -qa : Lists installed packages.
    • -q : Query mode.
    • -a : Queries all installed packages.
  • rpm -qi <pkg> : Shows installed package metadata.
    • -i : Displays package information (name, version, release, summary, etc.).
  • rpm -ql <pkg> : Lists files installed by a package.
    • -l : Lists files for the queried package.
  • rpm -qf <path> : Identifies which package owns a file path.
    • -f : Queries by file ownership.
  • rpm -V <pkg> : Verifies installed package contents against packaged state.
    • -V : Verification mode (checksums, permissions, sizes, timestamps, etc.).
  • rpm -K <file.rpm> : Validates digests and signatures for a local RPM file.
    • -K : Checks package signature and digest information.
  • rpm -qp --info <file.rpm> : Queries metadata from an RPM file without installing it.
    • -p : Operates on a package file instead of the installed database.
    • --info : Displays package information for the file.
  • rpm -Uvh <file.rpm> : Installs or upgrades from a local RPM file.
    • -U : Upgrades if installed, otherwise installs.
    • -v : Verbose output.
    • -h : Prints hash marks to show progress.
  • rpm -e <pkg> : Removes a package (erase).
    • -e : Erases the package and owned files (dependency checks apply).
  • rpm --rebuilddb : Rebuilds the RPM database as a recovery operation.
    • --rebuilddb : Recreates database indexes from installed package headers.