The cache is bloated or corrupted
You run sudo dnf upgrade and the terminal hangs for twenty minutes while it prints Loading mirror speeds. Or your disk usage hits 95% and dnf refuses to install anything because the transaction test needs temporary space. The cache has grown too large, or the metadata is corrupted. You need to clear the cache to restore performance and reclaim gigabytes of disk space.
What DNF caches and why it matters
DNF keeps a local copy of repository metadata and downloaded packages. This cache speeds up future operations. When you run dnf install, DNF downloads the RPM files to /var/cache/dnf. It also downloads metadata files like repomd.xml and primary.xml to know what packages exist and their dependencies.
The metadata tells DNF which packages are available, their versions, and how they relate to each other. DNF uses this information to resolve dependencies without querying the remote repository every time. The package cache stores RPM files so you can reinstall packages without downloading them again.
Over time, old package versions accumulate. Metadata can become stale if the repository updates but your local copy doesn't refresh. A bloated cache wastes disk space. Stale metadata causes dependency resolution errors. The cache is a performance optimization, not a permanent storage requirement. You can delete it safely. DNF will rebuild it on the next operation.
The transaction test is the most sensitive part of the cache. When you run an upgrade, DNF unpacks packages to /var/tmp/dnf-* to verify integrity and check for conflicts. If /var is full, the transaction test fails and the upgrade aborts. Cleaning the cache frees space in /var/cache/dnf, which helps the transaction test succeed.
The cache is a speed bump, not a wall. Clear it when it blocks you.
Clear the cache safely
Run sudo dnf clean all to remove everything. This command clears the entire cache directory. It removes downloaded RPM packages, metadata files, and the internal RPM database cache. Use this when you suspect corruption or need maximum space recovery.
sudo dnf clean all
# Removes metadata, packages, headers, and rpmdb cache
# Frees space in /var/cache/dnf immediately
# Forces DNF to re-download metadata on next run
If you only need to free space from large RPM files, use sudo dnf clean packages. This leaves metadata in place. DNF won't need to re-download the repository index, so the next dnf list or dnf install starts faster.
sudo dnf clean packages
# Removes only downloaded RPM files
# Keeps metadata intact for faster dependency resolution
# Useful when disk space is tight but metadata is valid
Use sudo dnf clean expire-cache to mark metadata as expired without deleting it. DNF will treat the metadata as stale and re-download it on the next operation. This is useful when you suspect the repository has updated but DNF hasn't noticed.
sudo dnf clean expire-cache
# Marks metadata as expired without deleting files
# Forces DNF to refresh metadata on next operation
# Faster than clean all when metadata is likely valid
Run dnf clean all before you guess. A fresh cache eliminates half the false errors.
Verify the cleanup
Check the cache size to confirm space was reclaimed. Run du -sh /var/cache/dnf to see the total size. A clean cache should only contain metadata, which is usually small. If the size is still large, check for other consumers of disk space.
du -sh /var/cache/dnf
# Shows total size of DNF cache directory
# Confirms space was reclaimed after clean command
# Output should be small, typically under 100MB for metadata only
If the cache size is still large after clean all, inspect the directory manually. Run ls -lh /var/cache/dnf to see which repositories are using space. Some third-party repositories might have custom cache configurations that prevent cleanup.
Check the journal for errors if dnf still fails after cleaning. Run journalctl -xeu dnf to see recent errors. The x flag adds explanatory text and e jumps to the end. This often reveals network timeouts or permission issues that the main output hides.
journalctl -xeu dnf
# Shows recent DNF logs with explanatory text
# Jumps to the end of the log for latest errors
# Reveals hidden failures like network timeouts or SELinux denials
Check the size. If it's still huge, the cache isn't the problem.
Common errors and recovery
If you see Error: Cannot prepare internal mirrorlist, the metadata is likely corrupted or the mirror list is broken. Running sudo dnf clean all often fixes this by forcing a fresh download. The error usually looks like this:
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Could not resolve host
This error indicates a network issue or a corrupted mirror list. Cleaning the cache removes the broken mirror list. DNF will download a fresh copy on the next run.
If dnf crashes during an upgrade, the cache might be in an inconsistent state. The RPM database could be locked. Run sudo rm -f /var/run/dnf.pid to remove the stale lock file. Then run sudo dnf clean all and retry.
sudo rm -f /var/run/dnf.pid
# Removes stale lock file if DNF crashed
# Allows new DNF process to acquire lock
# Only run if you are sure no DNF process is running
Check for running processes first. Run ps aux | grep dnf. If a DNF process is still running, wait for it to finish or kill it carefully. Removing the PID file while DNF is active can corrupt the database.
If the RPM database is corrupted, run sudo rpm --rebuilddb. This rebuilds the RPM database from the installed files. It takes time but fixes most database errors.
sudo rpm --rebuilddb
# Rebuilds RPM database from installed files
# Fixes corrupted database errors
# Takes several minutes on large systems
Read the journal before you reboot. The error message tells you exactly what broke.
Beyond the cache: Orphaned packages and configuration
Cleaning the cache reclaims space used by temporary files. It does not remove installed packages or orphaned dependencies. If your disk is still full after cleaning, run sudo dnf autoremove. This command removes packages that were installed as dependencies but are no longer required by any installed package. Review the list carefully before confirming. dnf autoremove can remove packages you installed manually if they are no longer dependencies of anything else.
sudo dnf autoremove
# Lists packages no longer needed as dependencies
# Prompts for confirmation before removal
# Reclaims space from orphaned packages
DNF manages cache automatically to some extent. It removes old packages that are no longer available in the repository. However, it keeps the latest version of every package in the cache. This allows you to reinstall packages without downloading them again. If you have limited disk space, you can configure DNF to keep fewer cached packages. Edit /etc/dnf/dnf.conf. Add keepcache=0 to disable package caching entirely. This saves space but increases download traffic. The default is keepcache=0 in modern Fedora, so packages are removed after installation. If you see large RPM files in the cache, they might be from a failed transaction or a custom repo configuration.
Configuration files in /etc/dnf/ override package defaults. Files in /usr/lib/dnf/ ship with the package and get overwritten on update. Always modify /etc/dnf/dnf.conf for persistent changes. Never edit /usr/lib/dnf/dnf.conf.
Use dnf upgrade --refresh for weekly maintenance. This forces metadata refresh without cleaning the whole cache. It keeps metadata current without the overhead of a full clean. dnf clean all is for troubleshooting or space recovery, not routine updates.
Run autoremove after every major feature removal. Dependencies pile up silently.
Decision matrix
Use sudo dnf clean all when you need to recover disk space or fix metadata corruption errors.
Use sudo dnf clean packages when you want to free space from RPM files but keep metadata for faster resolution.
Use sudo dnf clean expire-cache when you suspect the repository has updated but DNF hasn't noticed.
Use sudo dnf autoremove when you want to remove orphaned dependencies that are no longer needed by installed packages.
Use sudo dnf makecache when you want to pre-download metadata for offline dependency resolution.
Stay on dnf upgrade --refresh for routine updates to keep metadata current without clearing the cache.