We have all been there. You run a quick update, dnf sits there hanging on a specific repository, and eventually throws a timeout error that tells you absolutely nothing useful. You check the status of the mirror, it is up, but your local cache is convinced the world ended three hours ago. It is a classic case of local metadata drift causing a total stall.

Why the cache decides to hold onto garbage

The issue usually stems from the way dnf handles expiration headers from mirrors. If a mirror is partially synced or behind a load balancer with a confused configuration, you get stuck with an incomplete repository XML. Dnf then tries to validate files against this broken metadata, leading to the dreaded stalled state. Most people reach for a full clean all, but that is overkill and forces you to re-download gigabytes of repo data unnecessarily.

sudo dnf clean metadata && sudo dnf makecache --refresh

• clean metadata only purges the XML data, not the actual package binaries or headers
• makecache –refresh forces dnf to ignore existing expiration timestamps
• check /var/cache/dnf to see if a specific repo directory is permanently corrupted

Dealing with the ghost in the machine

If that does not clear it, you are likely looking at a proxy caching issue between you and the repository. Before you start editing baseurls, try running the command with the –setopt=fastestmirror=false flag. Sometimes the plugin tries to be too clever and pins you to a mirror that is currently serving 404s for the repomd.xml file. Keep this in mind next time you see a hung dnf session; clear the metadata, verify your mirror health, and move on.