We have all been there. You run dnf update on a machine with a massive catalog of installed packages, and instead of just showing you the list of updates, the process sits there at 100 percent CPU for a full minute. It is not fetching data, and it is not installing anything yet. It is stuck in that weird limbo where the dependency solver is basically trying to map the entire multiverse of your repo configuration.

Why DNF sometimes thinks it needs to rebuild the world

The underlying problem is how dnf handles the SQLite metadata. If your repodata is slightly stale or if you have a bloated mix of local and network repositories, the solver gets confused. It attempts to re-calculate every possible transaction set before it even prompts you for a confirmation. This is why it feels like the tool is frozen when in reality it is just burning cycles on a job it shouldn’t even be doing.

dnf clean metadata && dnf makecache --timer

• Check /etc/dnf/dnf.conf for excessive metadata expiry times that force a full sync
• Prune disabled repositories that still contain heavy metadata files in /var/cache/dnf
• Disable the fastestmirror plugin if you are on a stable, high-bandwidth internal network

Most admins assume dnf needs to do this deep work to keep things safe. But if you are managing a fleet, you should be pushing pre-generated repo metadata anyway. If your local metadata cache is consistently causing hangs, manually blowing away the cache directory is faster than waiting for the internal cleanup to finish. Just make sure you are not hitting the network hard right after, or you will be back to waiting for the transfer instead of the parsing.

Next time the solver hangs, grab a stack trace or check the process tree. If you see it pegged on dnf.librepo, you know exactly what is happening. Use this to skip the manual cleanup loop next time you are building base images.