Fix dnf "Failed to download metadata for repo" and "Cannot download repomd.xml"

ping -c2 mirrors.fedoraproject.org
sudo dnf clean all
sudo dnf makecache
# still failing for one repo (name is in the error):
sudo dnf upgrade --disablerepo=REPO-NAME

What the error means

With DNF5 (Fedora 41 and later, including Fedora 44 and 45) the message looks like this:

Updating and loading repositories:
 Copr repo for foo owned by bar           100% |   1.2 KiB/s |   0.4 KiB |  00m00s
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/bar/foo/fedora-45-x86_64/repodata/repomd.xml
>>> Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Failed to download metadata (baseurl: "https://download.copr.fedorainfracloud.org/results/bar/foo/fedora-45-x86_64/") for repository "copr:copr.fedorainfracloud.org:bar:foo"

Older dnf (Fedora 40 and earlier, RHEL 8/9 and clones) prints:

Errors during downloading metadata for repository 'fedora':
  - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-40&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name

Each repository publishes an index at repodata/repomd.xml. dnf downloads it (via a metalink or mirrorlist for official repos) before any install or upgrade. If it cannot, it stops. The detail after Curl error or Status code tells you which cause you have:

Cause 1: no network or DNS

The most common cause on laptops and freshly installed VMs: the network is down, a VPN broke DNS, or a captive portal is waiting for you to log in.

ping -c2 1.1.1.1                  # raw connectivity
ping -c2 mirrors.fedoraproject.org  # DNS
resolvectl status

If the IP works but the name does not, it is a DNS problem; see "Temporary failure in name resolution". If you are behind a proxy, set it for dnf in /etc/dnf/dnf.conf with proxy=http://proxy.example:3128.

Cause 2: a Copr or third-party repo without packages for your release

Right after a release upgrade (Fedora 45 ships on 20 October 2026), Copr projects, vendor repos and sometimes RPM Fusion's nonfree tainted or extra repos may not have fedora-45 builds yet. The error shows a 404 for that repo only. Find and disable it:

dnf repo list --all
# DNF5 (Fedora 41+)
sudo dnf config-manager setopt REPO-ID.enabled=0
# or for a Copr
sudo dnf copr disable owner/project

On older dnf4 systems the syntax is sudo dnf config-manager --set-disabled REPO-ID. Re-enable it once the project publishes builds for your release. To run a single command without the repo, use --disablerepo=REPO-ID, or let dnf continue when that repo is unreachable with --setopt=REPO-ID.skip_if_unavailable=True. DNF5 defaults skip_if_unavailable to false, which is why one broken repo stops everything.

Before an upgrade, the Fedora upgrade guide shows how to check third-party repos so this does not block dnf system-upgrade.

Cause 3: stale or corrupted cache

An interrupted download or a mirror that was mid-sync can leave bad metadata in /var/cache/libdnf5 (DNF5) or /var/cache/dnf (dnf4).

sudo dnf clean all
sudo dnf makecache

If checksum or signature errors persist on official Fedora repos, a bad mirror is likely; running the command again usually picks a different mirror through the metalink. You can force a specific mirror temporarily by setting baseurl= in the repo file under /etc/yum.repos.d/ and commenting out metalink=.

Cause 4: your release is end-of-life

Fedora mirrors drop old releases after end of life (Fedora 43 reaches EOL on 9 December 2026). An EOL release eventually gets 404s for updates and fedora. Upgrade to a supported release; the content stays available on archives.fedoraproject.org, which you can use as a temporary baseurl to get the upgrade tools working.

On RHEL clones the classic case is CentOS Linux 8, whose repos were removed after EOL:

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

Migrate to Rocky Linux, AlmaLinux or CentOS Stream. As a short-term stopgap only, change the repo files to point at vault.centos.org.

Cause 5: clock, certificates or IPv6

• Wrong clock (dead CMOS battery, VM restored from a snapshot): TLS certificates appear not yet valid or expired. Fix with sudo timedatectl set-ntp true.
• Corporate TLS inspection: install the company CA into /etc/pki/ca-trust/source/anchors/ and run sudo update-ca-trust.
• Broken IPv6: the network advertises IPv6 but does not route it, so connections time out. Test with curl -6 -I https://mirrors.fedoraproject.org; set ip_resolve=4 in /etc/dnf/dnf.conf as a workaround and fix the network later.

Distro-specific notes

• Fedora 44/45 (DNF5): repo IDs are shown in quotes after for repository. Use dnf repo info REPO-ID to see its URL. Atomic desktops (Silverblue, Kinoite) use rpm-ostree, which reports the same problem as a curl or 404 error for a repo in /etc/yum.repos.d/.
• RHEL: a 403 on cdn.redhat.com means the subscription is missing or expired; run sudo subscription-manager status.
• openSUSE (zypper) reports the same situation as Download (curl) error or Valid metadata not found at specified URL; disable a broken repo with sudo zypper modifyrepo -d ALIAS and refresh with sudo zypper refresh.
• Debian/Ubuntu: the apt equivalent is "does not have a Release file".

How to prevent it

• Keep only the Copr and third-party repos you use; check them before each release upgrade.
• Stay on a supported Fedora release; each one gets about 13 months of updates. The Fedora reference lists current support dates.
• Keep NTP enabled so certificates validate.

Frequently asked questions