[…] Error: Failed to download metadata for repo 'baseos': Yum repo downloading error: Downloading error(s): repodata/4c8f7fb3-faea-48a0-a911-7ea99aa7b98b-PRIMARY.xml.gz - Cannot download, all mirrors were already tried without success; repodata/23ff28be-481b-4f76-922b-e0e1c1860bbd-GROUPS.xml.gz - Cannot download, all mirrors were already tried without success
When I don’t use mirrorlist but use an explicit mirror I do not get any errors and refreshing works fine. E.g.: #baseurl=https://mirror1.hs-esslingen.de/pub/Mirrors/rocky/9.5/BaseOS/x86_64/os/
Same here.
I also get a similar error message when switching to Rocky Linux 8 (just tried both when creating containers).
Part of the file names seems wrong. E.g. getting 404 for ‘4c8f7fb3-faea-48a0-a911-7ea99aa7b98b-PRIMARY.xml.gz’ when the file on the server is actually named ‘02481646-5fa6-4614-8572-648cbf75b05a-PRIMARY.xml.gz’.
AFAIK, dnf should fetch repodata/repomd.xml from URL(s) that it gets from the mirrorlist server.
That file (repomd.xml) has names of the other metadata files.
The screenshot shows names, like 77ca… and aa78…, but the “working” repos have now files with different names (in the repodata subdirectory.
Logically, either some of the repos are/were not properly in sync, or dnf has stale cached repomd.xml.
For the latter, the dnf clean all should help.
For the former … is there a https proxy in use? Something that could be out of sync with the repos?
‘dnf clean all’ - has no success - still at RL9.5 : Cannot download, all mirrors were already tried without success; repodata/23ff28be-481b-4f76-922b-e0e1c1860bbd-GROUPS.xml.gz / repodata/4c8f7fb3-faea-48a0-a911-7ea99aa7b98b-PRIMARY.xml.gz - Cannot download, all mirrors were already tried without success; repodata/23ff28be-481b-4f76-922b-e0e1c1860bbd-FILELISTS.xml.gz
Same here: filenames that are looked for by dnf are plain wrong and don’t exist on target servers. Also tried from different networks, so proxy/firewall is not the problem. “dnf clean all” and “dnf makecache” then fail accordingly for the same reason - hen-egg-problem i guess? One thing is for sure: problem is caused by “rocky-repos-9.5-1.3.el9.noarch”/“rocky-release-9.5-1.3.el9.noarch”, because my recent update to that at 2025-05-07 still succeeded. Is there any fixed repo definition package available? Desperately need those updates :-/ All the best
It’s obviously sporadic, since all my Rocky boxes are working fine with mirrorlist, so affects some people more than others. Possibly geographic based on the mirrors selected or fastly cache at certain geo locations causing it.
EPEL is not managed by Rocky, so we cannot help there. Incidently, those EPEL checksum errors have also been affecting CentOS Stream and Fedora as well.
Ahhh, thank you for your info!
Just thought, maybe some intermediate distribution infrastructure…
I realise i know far too little about the entire repo infra :-/
Which also indicates how marvelously this typically works.
As a quickfix for EPEL, the following helps according to vmaibaum’s approach:
I am not able to reproduce the errors you are having. I’ve tried from 15 servers across the globe and have not had a single failure upgrading.
The screenshots and texts provided here make it obvious that incorrect metadata is being fetched. More than likely, there areone or two mirrors out of sync and they may be causing this more widespread problem. In other words: if one mirror is handing bad metadata, of course no other mirrors will have those files.
That package update is entirely unrelated to any issues you are seeing. Repo configs were not mutated.
Those, who do get that kind of 404 error, could fetch repomd.xml from each of the servers listed in the error message and check which of them differ (from known “good” version).
