How to install an RPM file on Linux: dnf, rpm -ivh and yum

Short answer: on Fedora, Rocky Linux, AlmaLinux, RHEL or CentOS Stream, install a downloaded package with sudo dnf install ./package.rpm. dnf installs the file and fetches any missing dependencies from your enabled repositories. sudo rpm -ivh package.rpm installs it too, but stops with Failed dependencies when something is missing. On older systems such as CentOS 7, yum works the same way.

sudo dnf install ./package.rpm          # install a local file, dependencies included
sudo dnf upgrade ./package-2.0.rpm      # move to a newer file later
rpm -qa | grep -i package               # is it installed, and which version?
sudo dnf remove package                 # remove it by package name, not file name

The commands on this page follow the rpm(8) and rpmkeys(8) man pages of RPM 6.1 and the DNF and DNF5 references, read on 21 October 2026. The output blocks show the formats those tools print, with example package names; they were not captured from a live system for this page. Not sure which family you are on? Run cat /etc/os-release first, or see how to check your Linux version.

RPM cheat sheet: dnf and rpm side by side

How do I install an RPM file with dnf?

dnf install accepts a path to a local .rpm file in the same place it accepts a package name. It reads the package’s requirements, compares them with what is installed, adds whatever is missing from the enabled repositories, shows the whole transaction and asks before it changes anything:

$ sudo dnf install ./app-1.4.2-1.el9.x86_64.rpm
Dependencies resolved.
==========================================================================
 Package        Architecture   Version          Repository            Size
==========================================================================
Installing:
 app            x86_64         1.4.2-1.el9      @commandline         2.1 M
Installing dependencies:
 libfoo         x86_64         2.3-4.el9        appstream            180 k

Transaction Summary
==========================================================================
Install  2 Packages

Is this ok [y/N]:

@commandline marks the package that came from your file; the dependency came from the appstream repository. Three details are worth knowing:

• The ./ prefix. It makes clear that you mean a file in the current directory and not a package called that. A full path works the same way: sudo dnf install ~/Downloads/app.rpm.
• Several files at once. sudo dnf install ./a.rpm ./b.rpm resolves the files against each other, which is how vendors that ship a program as two or three RPMs expect them to be installed.
• Scripts. Add -y to answer yes automatically. Older guides write dnf localinstall; DNF documents that as a deprecated alias, so use plain install.

yum on older systems

On CentOS 7 and RHEL 7 the same job is sudo yum install ./package.rpm; yum also resolves dependencies. On RHEL 8 and later, and on everything built from it, yum is only another name for dnf, so a tutorial that says yum still works there. If the shell answers yum: command not found instead, you are on a different family altogether: see yum: command not found for the equivalents. openSUSE uses its own front end for the same files: sudo zypper install ./package.rpm.

rpm -ivh: installing without dependency resolution

rpm is the low-level tool underneath dnf. It installs exactly the files you give it and nothing else: -i installs, -v prints the package names and -h draws the progress bar of hash marks. When a requirement is not installed, it refuses:

$ sudo rpm -ivh app-1.4.2-1.el9.x86_64.rpm
error: Failed dependencies:
	libfoo.so.2()(64bit) is needed by app-1.4.2-1.el9.x86_64

The simplest fix is to run the same file through dnf install ./ instead. If you want to know what provides the missing piece first, ask dnf with the exact string from the error: dnf provides 'libfoo.so.2()(64bit)'. When nothing provides it, the package was built for another release or needs a repository you have not enabled (EPEL is the usual one on Rocky and AlmaLinux).

The rpm man page itself calls -i “special usage” and says installations should normally be done with -U (--upgrade), which installs the package if it is absent and upgrades it if an older version is there. So rpm -Uvh file.rpm is the safer habit. rpm still has its place: on a machine with no repository access, for a set of files that only depend on each other (rpm -Uvh *.rpm), or with --test to see what a transaction would do without doing it.

Upgrade, reinstall and downgrade an RPM

sudo dnf upgrade ./app-1.5.0-1.el9.x86_64.rpm      # newer file, dependencies resolved
sudo rpm -Uvh app-1.5.0-1.el9.x86_64.rpm            # the same with rpm
sudo rpm -Fvh *.rpm                                  # only upgrade what is already installed
sudo dnf downgrade ./app-1.4.2-1.el9.x86_64.rpm     # go back to an older file

rpm -i on a package that is already installed stops with package app-1.4.2-1.el9.x86_64 is already installed; that message means you wanted -U or dnf reinstall. -F (--freshen) upgrades only the packages that already have an earlier version installed, which is handy for a folder of vendor updates.

Kernels are the one exception: never rpm -Uvh a kernel package. An upgrade replaces the old version, so the kernel you are running and the one you can fall back to would be gone. dnf treats kernels as “install-only” packages and keeps several side by side (three by default, set by installonly_limit), so use dnf install or rpm -ivh for a kernel RPM.

Query installed packages and RPM files

The query mode, rpm -q, answers most questions about what is on the system. Add -p to ask the same questions of a .rpm file you have not installed:

rpm -qa | grep -i nginx               # installed packages matching a name
rpm -qa --last | head                 # most recently installed first
rpm -q nginx                          # one package: prints its version, or "is not installed"
rpm -qi nginx                         # name, version, vendor, build date, summary
rpm -ql nginx                         # every file it installed
rpm -qc nginx                         # only its configuration files
rpm -qf /usr/sbin/nginx               # which package owns this file

rpm -qpi app.rpm                      # the same, for a file not yet installed
rpm -qpl app.rpm                      # files it would install
rpm -qpR app.rpm                      # what it requires
rpm -qp --scripts app.rpm             # the scripts it runs as root on install and removal

rpm -qp --scripts deserves a habit of its own for anything from outside your distribution: an RPM’s install scripts run as root, and this shows you what they do before they do it. After installation, rpm -V name compares the installed files with the package database and prints only those that changed. A line such as S.5....T. c /etc/app/app.conf means size, checksum and modification time differ from what was shipped, and the c marks a configuration file, where that is expected after you edited it.

How do I remove an RPM package?

Removal takes the package name, not the file name you installed from. If you only have the file, read the name out of it:

rpm -qp --qf '%{NAME}\n' app-1.4.2-1.el9.x86_64.rpm    # prints: app
sudo dnf remove app                 # also removes dependencies nothing else needs
sudo rpm -e app                     # removes only this package
sudo rpm -e --test app              # what rpm -e would do, without doing it

dnf remove also takes away the dependencies that were pulled in only for this package (clean_requirements_on_remove is on by default), and anything that depends on the package you remove, after showing you the list. rpm -e refuses when another installed package needs the one you name, with error: Failed dependencies and the name of the dependent package. If two versions of the same name are installed, give the full name, such as rpm -e app-1.4.2-1.el9.x86_64.

Check the signature before you install

An RPM from a vendor is normally signed with the vendor’s OpenPGP key. dnf checks repository packages against the keys configured for each repository, but for a local file it skips that check by default (localpkg_gpgcheck is off in both DNF and DNF5). So for a file you downloaded, check it yourself:

1. 1Check the file

   rpm -K app-1.4.2-1.el9.x86_64.rpm
   # app-1.4.2-1.el9.x86_64.rpm: digests signatures OK

   Classes that fail are printed in capitals, so digests SIGNATURES NOT OK means the file is intact but the signature cannot be checked, usually because the key is not imported. rpm -Kv names the key ID and says NOKEY in that case.

2. 2Import the vendor's public key

   sudo rpm --import https://vendor.example/RPM-GPG-KEY-vendor
   rpm -K app-1.4.2-1.el9.x86_64.rpm       # check again

   Take the key from the vendor’s own website or documentation, over HTTPS, never from the same unknown mirror as the file. rpmkeys --import is the same operation, and on RPM 6 rpmkeys --list shows the keys you have imported.

3. 3Compare the checksum if the vendor publishes one

   sha256sum app-1.4.2-1.el9.x86_64.rpm

rpm in the 4.x series installs a package whose key is missing with only a NOKEY warning. RPM 6 can enforce signatures instead, and Fedora’s accepted change for Fedora 45 makes that the default: an unsigned package is then refused unless you pass --nosignature. Treat that flag as the exception for packages you built yourself, not as a fix.

A repository beats a single RPM file

A package installed from a file is not updated by dnf upgrade unless some enabled repository carries the same package. Security fixes for it are then your job, file by file. Most vendors therefore offer a repository: a .repo file in /etc/yum.repos.d/, often installed by a small “release” RPM that also brings the signing key. EPEL on Rocky Linux and AlmaLinux works that way: sudo dnf install epel-release. A repository written by hand looks like this:

[vendor]
name=Vendor packages
baseurl=https://packages.vendor.example/rpm/el$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.vendor.example/RPM-GPG-KEY-vendor

After that, sudo dnf install vendor-app installs by name and every dnf upgrade keeps it current, with the signature checked. Use the single file only when there is no repository, and pick the build for your release: the el9 or fc41 in a file name says which distribution it was built for, and x86_64, aarch64 or noarch which CPU. rpm -E %rhel prints the major version on the RHEL family (9 on Rocky Linux 9), uname -m the architecture. A .src.rpm is source code, not an installable program.

How do I install an RPM on Ubuntu or Debian?

Look for a native package first. Most vendors that offer an RPM also offer a .deb or an apt repository, and installing a .deb file keeps the program inside apt’s view of the system. Do not install rpm or dnf on Ubuntu to run the file: Debian and Ubuntu package them for building and inspecting RPMs, and anything installed with them bypasses apt entirely.

If there really is only an RPM, alien converts it into a .deb:

sudo apt install alien
sudo alien --to-deb app-1.4.2-1.x86_64.rpm      # writes app_1.4.2-2_amd64.deb
sudo apt install ./app_1.4.2-2_amd64.deb

• alien raises the release number by one by default (the -2 above); -k keeps the original version.
• The RPM’s install and removal scripts are left out unless you add --scripts, which the man page says to use with caution because the scripts may be written for a system unlike yours. Read them first with rpm -qp --scripts or by extracting the package.
• Dependencies are named the Red Hat way, which means nothing to apt, so a missing library shows up only when the program starts; see error while loading shared libraries for tracking one down.
• The man page is explicit that alien must not replace important system packages such as the C library or init. Convert applications, never base packages.

Two alternatives avoid conversion. To get at the files without installing anything, unpack the archive: bsdtar -xf app.rpm (package libarchive-tools) extracts it into the current directory. To run the program on the kind of system it was built for, use a container from an RPM distribution, for example docker run --rm -it rockylinux/rockylinux:9, and install the file with dnf inside it.

Common RPM install errors

Installing RPMs on a server

On a server the same rule applies more strictly: everything should come from a repository, so that one dnf upgrade patches the whole machine. Keep a short list of anything installed from a single file and check those vendors for updates on a schedule. Before a larger change, take a snapshot, so a package that breaks the boot or the network is one restore away.

Our Linux VPS plans offer Rocky Linux 9 and CentOS Stream 9 as templates next to Ubuntu and Debian, all with full root, and snapshots and a browser-based VNC console are in the panel.

Frequently asked