Verification

DNF is the package manager you get on Fedora, RHEL 8 and later, Rocky Linux, AlmaLinux and Oracle Linux — and the commands below work the same on all of them.

This article shows you how to run the day-to-day package operations with DNF, how to read what it did to your system afterwards, and where the newer DNF5 behaves differently from the version you may have learned on. It is aimed at anyone who has shell access to a Red Hat-family machine and needs to install, update or roll back software without breaking it.

Requirements

• A Red Hat-family distribution: Fedora 22 or newer, RHEL 8 or newer, Rocky Linux 8/9/10, AlmaLinux 8/9/10, or Oracle Linux 8/9.
• Root or `sudo` privileges. DNF writes to `/var/lib/dnf` and `/var/cache/dnf`, so a normal user cannot complete a transaction.
• Working network access to your configured repositories. On an air-gapped host you need a local mirror or a mounted ISO repo before any of this works.
• `dnf` 4.x on RHEL 8/9 and Rocky/Alma 8/9. Fedora 41 and later ship `dnf5`, where `/usr/bin/dnf` is a symlink to `/usr/bin/dnf5`.

Check which one you have before you start, because the output format of a few subcommands changed between the two:

```bash dnf --version readlink -f "$(command -v dnf)" ```

If the second command prints `/usr/bin/dnf5`, you are on DNF5. Most of what follows is identical, and I flag the differences where they matter.

Steps

1. Refresh the metadata cache

DNF does not query repositories live on every command. It keeps a local copy of each repo's metadata in `/var/cache/dnf` and works from that. If the cache is stale, you are installing against an old view of the world.

```bash sudo dnf makecache ```

You do not strictly need this — `dnf install` refreshes metadata automatically when the cache has expired. But running it explicitly separates a network or repo problem from a package problem, which saves you guessing later. The default expiry is set per repo in `/etc/dnf/dnf.conf` via `metadata_expire`.

2. Search for a package

Before installing anything, find the exact name. Package names in the Red Hat ecosystem are not always what you expect — the `nginx` package is `nginx`, but the Python bindings for a library often live in a `python3-` prefixed package you have to install separately.

```bash dnf search nginx dnf info nginx ```

`search` matches on name and summary, so it returns noise. `info` gives you the version, the size, the repository it comes from, and the description. If you want to know which package owns a file you already have on disk, that is a different command:

```bash dnf provides /usr/sbin/nginx ```

`provides` is the one you reach for when something is missing and you do not know what to install. It also accepts a bare filename or a library soname, so `dnf provides 'libssl.so.3'` works.

3. Install a package

```bash sudo dnf install nginx ```

DNF resolves dependencies, shows you the full transaction — packages to install, packages to upgrade, packages to remove — and asks for confirmation. Read that list. The remove section is the one that bites: a plugin or a conflicting library can pull out something you were relying on, and DNF will happily tell you so if you look.

To skip the prompt in a script, add `-y`. That is fine for a build pipeline and a bad habit interactively, because you lose the one chance to see what is about to be removed from your system.

If you only want the package downloaded and not installed — for example to push an RPM to an offline host — use:

```bash dnf download nginx ```

That drops the RPM in your current directory and touches nothing else.

4. Update the system

```bash sudo dnf upgrade ```

`upgrade` and `update` are the same command in DNF; `update` is kept as an alias for muscle memory from YUM. It applies all available updates for installed packages, respecting your repo priorities and version locks.

For a single package:

```bash sudo dnf upgrade nginx ```

One thing worth knowing: `dnf upgrade` does not remove obsolete packages by default. On a long-lived system you accumulate packages that nothing depends on anymore. `dnf autoremove` clears them, but it will also remove anything you installed manually that is no longer a dependency of something else — so check the list before you confirm.

5. Remove a package

```bash sudo dnf remove nginx ```

DNF removes the package and any dependencies that were pulled in solely for it. It will not remove a dependency that something else still needs.

If you want the config files gone too, note that `remove` leaves files marked as configuration in `/etc` in place, renamed with a `.rpmsave` or `.rpmnew` suffix. That is deliberate: your edits survive a reinstall. If you genuinely want a clean slate, delete those manually after the fact. There is no `--purge` flag like on Debian, and that is a design choice, not an oversight.

6. Read the transaction history

Every DNF operation is recorded in a SQLite database under `/var/lib/dnf`. This is the feature that separates DNF from a lot of other package managers, and it is the one people underuse.

```bash dnf history ```

You get a numbered list: ID, command line, date, action, number of altered packages, and whether it succeeded. To see exactly what a transaction did:

```bash dnf history info 14 ```

Replace `14` with the ID you care about. This shows every package installed, upgraded, downgraded or removed in that transaction, with the from-version and to-version.

7. Undo a transaction

This is where the history pays off. If an upgrade broke something, you can reverse it.

```bash sudo dnf history undo 14 ```

DNF reads the recorded transaction and constructs the inverse: it reinstalls the old versions and removes what that transaction added. It is not magic — if a package has since been removed from the repositories, the undo fails on that package and tells you which one. For a broken upgrade on a production box, that is still far better than a manual downgrade hunt.

To redo a transaction you undid, use `dnf history redo 14`.

8. Manage repositories

DNF reads repo definitions from `/etc/yum.repos.d/*.repo`. On RHEL and its clones, most of these are managed by `subscription-manager` or by the `dnf config-manager` plugin.

```bash dnf repolist dnf repolist --all ```

`repolist` shows enabled repos only; `--all` includes disabled ones. To enable or disable a repo without editing files:

```bash sudo dnf config-manager --set-enabled epel sudo dnf config-manager --set-disabled epel ```

On DNF5 the syntax changed — `config-manager` became a subcommand with its own flags:

```bash sudo dnf config-manager setopt epel.enabled=1 ```

If you are on Fedora 41 or newer and the old flag form errors out, that is why. Check `dnf config-manager --help` on your machine rather than trusting a tutorial written before the switch.

Verification

Confirm the package is installed and see its version:

```bash rpm -q nginx ```

A clean answer looks like `nginx-1.24.0-1.el9.x86_64`. If it prints `package nginx is not installed`, the transaction did not complete — check `dnf history` for the last entry and whether it shows a failure.

To confirm the whole system is consistent and no dependencies are broken:

```bash sudo dnf check ```

Silence means clean. Any output names the package and the problem.

If you want to see what the last transaction actually did, without scrolling:

```bash dnf history info last ```

Common problems

"Failed to synchronize cache for repo" — the metadata download failed, usually a network or mirror problem, not a DNF bug. Clear the cache and retry:

```bash sudo dnf clean all sudo dnf makecache ```

If it persists on one repo, that mirror is likely down; disable it temporarily with `--disablerepo=` on the command line and let the others carry you.

"Error: Transaction check error: file /path conflicts between attempted installs" — two packages claim the same file. This happens most often when you mix a third-party repo (EPEL, a vendor repo) with base packages. Find out which packages are fighting:

```bash sudo dnf install --setopt=tsflags=test ```

The `test` flag runs the transaction without committing it, so you see the conflict without changing anything. Then decide which package you actually want and remove the other, or use `--exclude` on the repo you trust less.

"This command has to be run with superuser privileges" — you forgot `sudo`. DNF cannot write to its state directories as a normal user, and there is no per-user mode for system packages. For a user-local install without root, `dnf` is the wrong tool; you want a language-level package manager (pip, npm, cargo) or a container.

One more that is not an error but trips people up: on Fedora 41 and later, `dnf` is DNF5, and its output is terser and its flags are stricter. A script written for DNF 4 that parses `dnf` output will keep running but may parse nothing useful. If that matters to you, call `dnf4` explicitly where it is still installed, or pin your scripts to the version you tested against.