{"id":167920,"date":"2026-05-23T16:41:10","date_gmt":"2026-05-23T13:41:10","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=167920"},"modified":"2026-05-23T16:41:10","modified_gmt":"2026-05-23T13:41:10","slug":"dnf5-cheatsheet-fedora","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/dnf5-cheatsheet-fedora\/","title":{"rendered":"DNF5 Cheatsheet & Tips for Fedora 44 \/ 43 \/ 42"},"content":{"rendered":"

If you opened a terminal on a fresh Fedora install lately, you ran DNF5 whether you knew it or not. The legacy dnf<\/code> binary is gone from the default workstation; \/usr\/bin\/dnf<\/code> is a direct symlink to \/usr\/bin\/dnf5<\/code>, and the old Python-based DNF4 isn’t even in the base package set. Most online tutorials still show DNF4 syntax that quietly works through compatibility shims, which means readers paste outdated flags and miss the genuinely useful new subcommands.<\/p>\n\n

This dnf5 cheatsheet collects the commands that actually earn their place on a working Fedora box. Real syntax, captured from a Fedora 44 lab clone, covering search and install, groups and environments, COPR, transaction history and rollback, offline release upgrades, versionlock, and the speed knobs that most installs leave on conservative defaults. Every command in the article was executed; nothing was extrapolated from the man page. For the broader RHEL-family picture, the DNF package manager guide for Rocky and AlmaLinux<\/a> stays accurate for those distros.<\/p>\n\n

Tested May 2026<\/strong> on Fedora 44 (kernel 7.0.8-200.fc44), dnf5 5.4.2.1, libdnf5 5.4.2.1. Commands also verified on Fedora 43 and Fedora 42 clones.<\/em><\/p>\n\n

Verify DNF5 is your default<\/h2>\n\n

On Fedora 44 there is no DNF4 left on the system, but a quick sanity check pays for itself the first time someone hands you a borrowed VM. Check the binary and version:<\/p>\n\n\n

readlink -f \/usr\/bin\/dnf\ndnf5 --version<\/code><\/pre>\n\n\n
The first line should resolve to \/usr\/bin\/dnf5<\/code>. The version line confirms the engine and lists every loaded plugin. On a default F44 install, you should see something like this:<\/p>\n\n\n
dnf5 version 5.4.2.1\ndnf5 plugin API version 2.0\nlibdnf5 version 5.4.2.1\nlibdnf5 plugin API version 2.2\n\nLoaded dnf5 plugins:\n  name: builddep\n  name: changelog\n  name: config-manager\n  name: copr\n  name: needs_restarting\n  name: repoclosure\n  name: repomanage\n  name: reposync<\/code><\/pre>\n\n\n
If dnf<\/code> is missing on Fedora 43 or 42 (rare but possible after aggressive minimization), reinstall the metapackage with sudo dnf5 install dnf5 dnf5-plugins<\/code>. A clean run of the verification commands on a freshly-cloned Fedora 44 box looks like this:<\/p>\n\n\n
\"dnf5<\/figure>\n\n\n
The eight loaded plugins are what give DNF5 its modern feature surface: copr<\/code> for community repos, changelog<\/code> for RPM changelog inspection, config-manager<\/code> for repo management, and so on. Older Fedora releases that still shipped DNF4 alongside DNF5 typically loaded fewer plugins by default.<\/p>\n\n
Search and inspect packages<\/h2>\n\n
Most DNF5 sessions start by figuring out whether the thing you want is even packaged. Four commands cover 90% of that work: search<\/code>, info<\/code>, list<\/code>, and provides<\/code>.<\/p>\n\n\n
dnf5 search htop\ndnf5 info htop\ndnf5 list --installed \"kernel*\"\ndnf5 provides \/usr\/bin\/htop<\/code><\/pre>\n\n\n
The output of dnf5 list --installed \"kernel*\"<\/code> on a recently updated box shows every kernel still on disk, which is useful when GRUB is misbehaving or you need to free space:<\/p>\n\n\n
Installed packages\nkernel-core.x86_64         6.19.10-300.fc44 4e4a4f70cfdd4047b39087e8606c2591\nkernel-core.x86_64         7.0.8-200.fc44   updates\nkernel-core.x86_64         7.0.9-205.fc44   updates\nkernel-modules-core.x86_64 6.19.10-300.fc44 4e4a4f70cfdd4047b39087e8606c2591\nkernel-modules-core.x86_64 7.0.8-200.fc44   updates\nkernel-modules-core.x86_64 7.0.9-205.fc44   updates<\/code><\/pre>\n\n\n
For richer queries, repoquery<\/code> handles dependency walks. Common variants:<\/p>\n\n\n
dnf5 repoquery --requires htop\ndnf5 repoquery --whatrequires libcurl\ndnf5 repoquery --installonly\ndnf5 changelog htop<\/code><\/pre>\n\n\n
The changelog<\/code> subcommand is the DNF5 way to read RPM changelog entries without dropping into rpm -q --changelog<\/code>. It pulls from the repo metadata, so you can read changelogs for packages that aren’t installed yet.<\/p>\n\n
Install, reinstall, and remove packages<\/h2>\n\n
Single-package installs work exactly how you would expect. The verbs that pay off on F44 are swap<\/code> (atomic replace, useful for switching codec stacks) and autoremove<\/code> (clears leaf packages no longer needed). For a fresh install:<\/p>\n\n\n
sudo dnf5 install -y htop\nsudo dnf5 install -y --setopt=install_weak_deps=False htop\nsudo dnf5 reinstall -y htop\nsudo dnf5 remove -y htop\nsudo dnf5 autoremove -y<\/code><\/pre>\n\n\n
The install_weak_deps=False<\/code> flag is the cleanest way to get a slim install when a package pulls a long Recommends list you don’t want on a server. For the codec-swap pattern from the RPM Fusion multimedia codecs guide<\/a>:<\/p>\n\n\n
sudo dnf5 swap ffmpeg-free ffmpeg --allowerasing\nsudo dnf5 swap libavcodec-free libavcodec-freeworld --allowerasing<\/code><\/pre>\n\n\n
To see only the user-installed packages sitting at the top of the dependency tree (the ones you’d actually miss if they vanished), use the leaves<\/code> command. It’s perfect for auditing what’s actually on a box versus what came along as deps:<\/p>\n\n\n
dnf5 leaves | tail -20<\/code><\/pre>\n\n\n
Output is grouped: top-level user packages are flagged with a leading dash, and packages installed as their dependencies are indented underneath. A live install transaction shows DNF5’s per-step progress bars, which separate download, verify, prepare, and install phases distinctly:<\/p>\n\n\n
\"dnf5<\/figure>\n\n\n
Notice the four numbered phases at the bottom: each step’s bandwidth and elapsed time is reported separately, so a slow mirror or a failing GPG check shows up as a stalled bar in a specific phase rather than a generic timeout.<\/p>\n\n
Update and upgrade<\/h2>\n\n
DNF5 separates security advisories, minimal patches, and full upgrades into distinct verbs. Pick the one that matches your patching policy:<\/p>\n\n\n
sudo dnf5 check-upgrade\nsudo dnf5 upgrade -y\nsudo dnf5 upgrade-minimal -y\nsudo dnf5 distro-sync -y\nsudo dnf5 upgrade --advisory=FEDORA-2026-66bba52149<\/code><\/pre>\n\n\n
The upgrade-minimal<\/code> command picks the lowest version that fixes outstanding bugs, instead of the latest. On servers where you only want CVE fixes, this is the safer default. distro-sync<\/code> aligns every installed package with what the enabled repos currently ship, including downgrades, which is the command you want after disabling a third-party repo whose packages now outrank Fedora’s.<\/p>\n\n
To freeze a specific package at a known version (typical for kernel, glibc, or anything tied to a vendor support matrix), use versionlock<\/code>:<\/p>\n\n\n
sudo dnf5 install -y dnf5-plugins\nsudo dnf5 versionlock add kernel-core\nsudo dnf5 versionlock list\nsudo dnf5 versionlock delete kernel-core<\/code><\/pre>\n\n\n
Versionlock writes its entries to \/etc\/dnf\/versionlock.toml<\/code> (TOML, not the old INI format), so config-management tools can drop the file in directly.<\/p>\n\n
Groups and environments<\/h2>\n\n
Groups bundle related packages so you can install a whole role in one shot. Fedora ships dozens of them, from the obvious (Development Tools<\/code>) to the niche (Neuron Modelling Simulators<\/code>). List them, then inspect what a group actually contains before installing:<\/p>\n\n\n
dnf5 group list\ndnf5 group info \"Development Tools\"\nsudo dnf5 group install -y \"Development Tools\"<\/code><\/pre>\n\n\n
Environments are the layer above groups. The workstation-product-environment<\/code> is what Anaconda installs when you pick “Fedora Workstation” at install time; kde-desktop-environment<\/code> is the Plasma equivalent. List and inspect:<\/p>\n\n\n
dnf5 environment list\ndnf5 environment info workstation-product-environment<\/code><\/pre>\n\n\n
The list<\/code> output names every environment and whether it is installed on the current box:<\/p>\n\n\n
ID                                Name                                 Installed\ncustom-environment                Fedora Custom Operating System              no\nworkstation-product-environment   Fedora Workstation                          no\nserver-product-environment        Fedora Server Edition                       no\ncloud-server-environment          Fedora Cloud Server                        yes\nkde-desktop-environment           KDE Plasma Workspaces                       no\nkde-mobile-environment            KDE Plasma Mobile                           no<\/code><\/pre>\n\n\n
To swap a server install into a Plasma desktop without reinstalling, install the matching environment and reboot. The same machinery is what the KDE Plasma 6.6 on Fedora 44 walkthrough<\/a> uses under the hood.<\/p>\n\n
Repositories, COPR, and config-manager<\/h2>\n\n
Adding third-party repos used to mean dropping a .repo<\/code> file into \/etc\/yum.repos.d\/<\/code> by hand. DNF5 wraps that in a proper subcommand, with both repo-file URLs and ad-hoc baseurl options supported:<\/p>\n\n\n
dnf5 repo list\nsudo dnf5 config-manager addrepo --from-repofile=https:\/\/download.docker.com\/linux\/fedora\/docker-ce.repo\nsudo dnf5 config-manager setopt fedora-cisco-openh264.enabled=1\nsudo dnf5 config-manager disable fedora-cisco-openh264<\/code><\/pre>\n\n\n
The setopt<\/code> command is the per-repo equivalent of --setopt<\/code> on a single invocation, but it persists. Use it for things like raising priority or pinning excludepkgs<\/code> for a specific repo.<\/p>\n\n
COPR (Cool Other Package Repo) is Fedora’s user-contributed package hosting. The plugin gives you a clean enable\/disable interface without touching repo files:<\/p>\n\n\n
sudo dnf5 copr enable atim\/starship\nsudo dnf5 install -y starship\nsudo dnf5 copr list\nsudo dnf5 copr disable atim\/starship\nsudo dnf5 copr remove atim\/starship<\/code><\/pre>\n\n\n
The difference between disable<\/code> and remove<\/code> is important: disable<\/code> sets enabled=0<\/code> in the repo file (reversible), remove<\/code> deletes the file. For temporary debugging, always pick disable<\/code>.<\/p>\n\n
Manage transaction history and rollback changes<\/h2>\n\n
Every DNF5 transaction is journalled in \/var\/lib\/dnf\/history.sqlite<\/code>. The history<\/code> subcommand lists, inspects, undoes, and replays them. Start with the list:<\/p>\n\n\n
sudo dnf5 history list<\/code><\/pre>\n\n\n
You get one row per transaction with the actual command line, the timestamp, and how many packages were touched:<\/p>\n\n\n
ID Command line                           Date and time       Action(s) Altered\n 5 dnf -y upgrade                         2026-05-22 22:21:58                50\n 4 dnf install -y vim-enhanced curl wget  2026-05-18 04:04:54                94\n 3 dnf -y upgrade                         2026-05-18 04:03:34               222\n 2 dnf5 --config \/kiwi_dnf5.config -y     2026-04-22 13:59:09               246\n 1 dnf5 --config \/builddir\/result\/image\/  2026-04-22 13:58:50               186<\/code><\/pre>\n\n\n
Drill into a specific transaction to see exactly which packages moved and why (User, Dependency, Group):<\/p>\n\n\n
sudo dnf5 history info 5<\/code><\/pre>\n\n\n
The output groups everything for that transaction by action type, with the install reason tagged per package. Real history list and drill-down on a recently upgraded Fedora 44 box:<\/p>\n\n\n
\"dnf5<\/figure>\n\n\n
To undo a bad transaction (uninstalls anything it installed, reinstalls anything it removed), name it by ID:<\/p>\n\n\n
sudo dnf5 history undo 5<\/code><\/pre>\n\n\n
The replay<\/code> command goes further. You can store any transaction with --store=PATH<\/code>, then re-run that exact transaction on another box. This is the modern answer to “how do I reproduce my dev install on the prod box?”:<\/p>\n\n\n
sudo dnf5 install --store=\/tmp\/dev-install htop tmux fish\nsudo rsync -a \/tmp\/dev-install\/ user@prod:\/tmp\/dev-install\/\nssh user@prod \"sudo dnf5 replay \/tmp\/dev-install\"<\/code><\/pre>\n\n\n
Speed up DNF5 with parallel downloads and cache<\/h2>\n\n
The compiled default for max_parallel_downloads<\/code> is 3, which is conservative for modern fibre links. The max DNF5 will accept is 20. For most home and office connections, 10 is a sensible upper bound that doesn’t trip rate limits on Fedora’s mirror network. Edit the main config:<\/p>\n\n\n
sudo vi \/etc\/dnf\/dnf.conf<\/code><\/pre>\n\n\n
Replace the bare [main]<\/code> stub Fedora ships with these tuned defaults:<\/p>\n\n\n
[main]\ngpgcheck=True\ninstallonly_limit=3\nclean_requirements_on_remove=True\nbest=False\nskip_if_unavailable=True\nmax_parallel_downloads=10\nfastestmirror=True\ndefaultyes=True\nkeepcache=True<\/code><\/pre>\n\n\n
Setting fastestmirror=True<\/code> tells libdnf5 to pick mirrors by TCP socket latency rather than the order in the mirrorlist. The cost is a one-time latency probe; the win is download speed on every subsequent transaction. keepcache=True<\/code> means downloaded RPMs survive between transactions, so a retry after a failed upgrade doesn’t re-download 800 MB.<\/p>\n\n
Force a metadata refresh after editing the config and clear the cache if a previous transaction looks stale:<\/p>\n\n\n
sudo dnf5 makecache\nsudo dnf5 clean all\nsudo dnf5 clean packages<\/code><\/pre>\n\n\n
Upgrade between Fedora releases offline<\/h2>\n\n
Major-version upgrades (F43 to F44, F44 to F45) run as offline transactions: DNF downloads everything, you reboot, the actual upgrade runs in a minimal early-boot environment with no graphical session to interfere. The flow lives under the system-upgrade<\/code> subcommand. The full walkthrough is in the Fedora 43 to 44 upgrade guide<\/a>; the quick reference is here:<\/p>\n\n\n
sudo dnf5 upgrade -y\nsudo dnf5 system-upgrade download --releasever=44\nsudo dnf5 system-upgrade reboot\nsudo dnf5 system-upgrade status\nsudo dnf5 system-upgrade log\nsudo dnf5 system-upgrade clean<\/code><\/pre>\n\n\n
The download<\/code> step pulls the new release’s metadata and every upgraded package into a staging area without touching the running system. reboot<\/code> arms the early-boot transaction. After the upgrade boots back to your normal desktop, status<\/code> confirms the result and log<\/code> shows the dnf log from inside the upgrade transaction, which is invaluable when a package conflict aborts the upgrade mid-flight.<\/p>\n\n
For point-release sync without crossing a release boundary, offline-distrosync<\/code> is the sibling command. It runs a full distro-sync<\/code> as an offline transaction, useful when you want to align everything in one atomic reboot.<\/p>\n\n
DNF4 to DNF5 quick reference<\/h2>\n\n
If you came from DNF4 (Fedora 40 and older, or RHEL\/Rocky\/Alma 10), most muscle memory still works, but a handful of changes will trip you up. Worth knowing:<\/p>\n\n\n\n
Task<\/th>DNF4<\/th>DNF5<\/th><\/tr><\/thead>\n
Repo enable\/disable<\/td>dnf config-manager --enable repo<\/code><\/td>dnf5 config-manager enable repo<\/code><\/td><\/tr>\n
Add repo file<\/td>dnf config-manager --add-repo URL<\/code><\/td>dnf5 config-manager addrepo --from-repofile=URL<\/code><\/td><\/tr>\n
Persist a repo option<\/td>dnf config-manager --save --setopt<\/code><\/td>dnf5 config-manager setopt<\/code><\/td><\/tr>\n
List groups<\/td>dnf grouplist<\/code><\/td>dnf5 group list<\/code> (subcommand, not concatenated)<\/td><\/tr>\n
Show environments<\/td>dnf grouplist --hidden<\/code><\/td>dnf5 environment list<\/code><\/td><\/tr>\n
Versionlock<\/td>INI in \/etc\/dnf\/plugins\/versionlock.list<\/code><\/td>TOML in \/etc\/dnf\/versionlock.toml<\/code><\/td><\/tr>\n
Top-level packages<\/td>(no equivalent)<\/td>dnf5 leaves<\/code><\/td><\/tr>\n
Replay a transaction<\/td>(no equivalent)<\/td>dnf5 replay PATH<\/code><\/td><\/tr>\n
Offline distro-sync<\/td>dnf system-upgrade<\/code> only<\/td>dnf5 offline-distrosync<\/code><\/td><\/tr>\n<\/tbody>\n<\/table>\n\n
The DNF Python API was rewritten end to end; if you depended on DNF4’s Python module in custom scripts, port to libdnf5<\/code> bindings via python3-libdnf5<\/code>. The signatures are not source-compatible.<\/p>\n\n
Troubleshoot common DNF5 errors<\/h2>\n\n
Some failures are common enough to memorize the fix. Two that catch readers most often on Fedora 44:<\/p>\n\n
Error: “Public key for … is not installed”<\/h3>\n\n
This appears after enabling a new repo that ships its key separately. The fix imports the key and retries:<\/p>\n\n\n
sudo rpm --import https:\/\/download.docker.com\/linux\/fedora\/gpg\nsudo dnf5 install -y docker-ce<\/code><\/pre>\n\n\n
For RPM Fusion and other community repos, the GPG keys ship inside the bootstrap RPM, so installing the release package first is enough. The RPM Fusion setup guide<\/a> shows the full pattern.<\/p>\n\n
Error: “Problem: package X-Y.fc44.x86_64 from updates requires Z, but none of the providers can be installed”<\/h3>\n\n
A dependency a package needs is held back by a third-party repo or a versionlock. List active locks and disable suspect repos one at a time:<\/p>\n\n\n
sudo dnf5 versionlock list\nsudo dnf5 repo list --enabled\nsudo dnf5 upgrade --disablerepo=docker-ce-stable<\/code><\/pre>\n\n\n
If the conflict survives every repo being disabled except fedora<\/code> and updates<\/code>, you’ve hit a genuine packaging bug; report it in Fedora Bugzilla with the full transaction output. Otherwise the culprit is whichever repo, once disabled, lets the transaction resolve.<\/p>\n\n
Error: “Cannot download Packages\/X.rpm: All mirrors were tried”<\/h3>\n\n
Mirror selection went sideways. Force a fresh cache and retry, optionally raising retries<\/code>:<\/p>\n\n\n
sudo dnf5 clean all\nsudo dnf5 --setopt=retries=20 makecache\nsudo dnf5 upgrade -y<\/code><\/pre>\n\n\n
Annotated \/etc\/dnf\/dnf.conf reference<\/h2>\n\n
The keys most worth knowing for everyday Fedora work, all of which go under the [main]<\/code> section:<\/p>\n\n