Fedora 42 no longer is in the normal mirrors, only in archives, so 42 users can no longer update nor upgrade #13442

Closed
opened 2026-07-28 23:57:46 +00:00 by khaytsus · 8 comments

Describe the issue

Fedora 42 mirrors all seem to no longer be under the normal mirror manager links, and are currently only available via "archive" links. A user on #fedora on IRC was attempting to update from 42, and dnf update failed repeatedly with errors like:

Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml

root@noisy:# dnf clean all
Removed 138 files, 102 directories (total of 531 MiB). 0 errors occurred.
root@noisy:
# dnf update
Updating and loading repositories:
Fedora 42 - x86_64 - Updates 100% | 346.0 B/s | 784.0 B | 00m02s

Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620
Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620
Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620
Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620
Usable URL not found
TeamViewer - x86_64 100% | 199.0 KiB/s | 478.3 KiB | 00m02s
RPM Fusion for Fedora 42 - Nonfree 100% | 19.2 KiB/s | 86.5 KiB | 00m04s
Repo for the unofficial Teams for Linux package 100% | 1.7 KiB/s | 4.2 KiB | 00m03s
gitlab.com_paulcarroty_vscodium_repo 100% | 2.4 KiB/s | 6.3 KiB | 00m03s
Google Cloud CLI 100% | 465.0 KiB/s | 1.0 MiB | 00m02s
Copr repo for globalprotect-openconnect owned by yuezk 100% | 1.4 KiB/s | 3.0 KiB | 00m02s
openHAB Stable 100% | 5.8 KiB/s | 16.2 KiB | 00m03s
RPM Fusion for Fedora 42 - Free - Updates 100% | 19.2 KiB/s | 89.9 KiB | 00m05s
slack 100% | 1.9 KiB/s | 6.1 KiB | 00m03s
RPM Fusion for Fedora 42 - Free 100% | 37.2 KiB/s | 163.4 KiB | 00m04s
RPM Fusion for Fedora 42 - Nonfree - Updates 100% | 9.1 KiB/s | 38.5 KiB | 00m04s
google-chrome 100% | 1.3 KiB/s | 3.3 KiB | 00m02s
Fedora 42 openh264 (From Cisco) - x86_64 100% | 1.5 KiB/s | 5.8 KiB | 00m04s
Fortinet CentOS 7 repository 100% | 1.9 KiB/s | 5.8 KiB | 00m03s
Fedora 42 - x86_64 100% | 6.6 MiB/s | 35.2 MiB | 00m05s
Failed to download metadata (baseurl: "https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/") for repository "updates": Usable URL not found
root@noisy:~#

I looked around for a few minutes to see what I was seeing on mirrors, and every 42 mirror I saw was empty. If I go to "archive" mirrors, they were still populated. For now, the user switched to a baseurl pointing an an archive link to work around their issue:

baseurl=https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/$releasever/Everything/$basearch/

Looking into this more, I looked at mirrormanager to show what 42 mirrors still exist for x86_64

https://mirrormanager.fedoraproject.org/mirrors/Fedora/42/x86_64

Note that all URLs are noted as "Fedora Archive". I've never seen Fedora retire a release on the mirrors so quickly. This most likely means any users who have not updated yet will have problems updating.

When do you need this? (YYYY/MM/DD)

I realize that 42 went EOL a few months ago, but if this does break anyones update who hasn't updated yet I'd think fixing it sooner than later is good.

When is this no longer needed or useful? (YYYY/MM/DD)

Hard for me to say on this one, again, I realize 42 is EOL but there are certainly still users on it, or systems they haven't used in a while, etc.

If we cannot complete this, what is the impact? [Dependencies/Blocker]

From what I can tell, unless users figure out how to change the baseurl to an archive link, they won't be able to update.


Checklist

  • I have checked existing issues for duplicates
  • I have filled out all the fields above
  • I have provided relevant links or references (if applicable)
## Describe the issue Fedora 42 mirrors all seem to no longer be under the normal mirror manager links, and are currently only available via "archive" links. A user on #fedora on IRC was attempting to update from 42, and dnf update failed repeatedly with errors like: Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml root@noisy:~# dnf clean all Removed 138 files, 102 directories (total of 531 MiB). 0 errors occurred. root@noisy:~# dnf update Updating and loading repositories: Fedora 42 - x86_64 - Updates 100% | 346.0 B/s | 784.0 B | 00m02s >>> Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620 >>> Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620 >>> Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620 >>> Status code: 404 for https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/repodata/repomd.xml (IP: 2620 >>> Usable URL not found TeamViewer - x86_64 100% | 199.0 KiB/s | 478.3 KiB | 00m02s RPM Fusion for Fedora 42 - Nonfree 100% | 19.2 KiB/s | 86.5 KiB | 00m04s Repo for the unofficial Teams for Linux package 100% | 1.7 KiB/s | 4.2 KiB | 00m03s gitlab.com_paulcarroty_vscodium_repo 100% | 2.4 KiB/s | 6.3 KiB | 00m03s Google Cloud CLI 100% | 465.0 KiB/s | 1.0 MiB | 00m02s Copr repo for globalprotect-openconnect owned by yuezk 100% | 1.4 KiB/s | 3.0 KiB | 00m02s openHAB Stable 100% | 5.8 KiB/s | 16.2 KiB | 00m03s RPM Fusion for Fedora 42 - Free - Updates 100% | 19.2 KiB/s | 89.9 KiB | 00m05s slack 100% | 1.9 KiB/s | 6.1 KiB | 00m03s RPM Fusion for Fedora 42 - Free 100% | 37.2 KiB/s | 163.4 KiB | 00m04s RPM Fusion for Fedora 42 - Nonfree - Updates 100% | 9.1 KiB/s | 38.5 KiB | 00m04s google-chrome 100% | 1.3 KiB/s | 3.3 KiB | 00m02s Fedora 42 openh264 (From Cisco) - x86_64 100% | 1.5 KiB/s | 5.8 KiB | 00m04s Fortinet CentOS 7 repository 100% | 1.9 KiB/s | 5.8 KiB | 00m03s Fedora 42 - x86_64 100% | 6.6 MiB/s | 35.2 MiB | 00m05s Failed to download metadata (baseurl: "https://dl.fedoraproject.org/pub/fedora/linux/updates/42/Everything/x86_64/") for repository "updates": Usable URL not found root@noisy:~# I looked around for a few minutes to see what I was seeing on mirrors, and every 42 mirror I saw was empty. If I go to "archive" mirrors, they were still populated. For now, the user switched to a baseurl pointing an an archive link to work around their issue: baseurl=https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/$releasever/Everything/$basearch/ Looking into this more, I looked at mirrormanager to show what 42 mirrors still exist for x86_64 https://mirrormanager.fedoraproject.org/mirrors/Fedora/42/x86_64 Note that all URLs are noted as "Fedora Archive". I've never seen Fedora retire a release on the mirrors so quickly. This most likely means any users who have not updated yet will have problems updating. ## When do you need this? (YYYY/MM/DD) I realize that 42 went EOL a few months ago, but if this does break anyones update who hasn't updated yet I'd think fixing it sooner than later is good. ## When is this no longer needed or useful? (YYYY/MM/DD) Hard for me to say on this one, again, I realize 42 is EOL but there are certainly still users on it, or systems they haven't used in a while, etc. ## If we cannot complete this, what is the impact? [Dependencies/Blocker] From what I can tell, unless users figure out how to change the baseurl to an archive link, they won't be able to update. --- ## Checklist - [x] I have checked existing issues for duplicates - [x] I have filled out all the fields above - [x] I have provided relevant links or references (if applicable)
Member

F-42 is EOL so there won't be upgrades, upgrades to f43+ will work though, although I did think mirrormanager did redirect to the archives.

F-42 is EOL so there won't be upgrades, upgrades to f43+ will work though, although I did think mirrormanager did redirect to the archives.
Owner

Not sure what is the requirement here, when a release is EOL, there are no upgrades, and the release is moved to archived and so the mirrormanager redirects.

The archived content are available under:

/pub/archive/fedora/linux/releases/42
/pub/archive/fedora/linux/updates/42
/pub/archive/fedora/linux/updates/testing/42
/pub/archive/fedora-secondary/releases/42
/pub/archive/fedora-secondary/updates/42
/pub/archive/fedora-secondary/updates/testing/42

This includes all necessary content for releases, updates, and
updates/testing for both the primary and secondary architectures.

Not sure what is the requirement here, when a release is EOL, there are no upgrades, and the release is moved to archived and so the mirrormanager redirects. The archived content are available under: /pub/archive/fedora/linux/releases/42 /pub/archive/fedora/linux/updates/42 /pub/archive/fedora/linux/updates/testing/42 /pub/archive/fedora-secondary/releases/42 /pub/archive/fedora-secondary/updates/42 /pub/archive/fedora-secondary/updates/testing/42 This includes all necessary content for releases, updates, and updates/testing for both the primary and secondary architectures.
Member

@jnsamyak wrote in #13442 (comment):

Not sure what is the requirement here, when a release is EOL, there are no upgrades, and the release is moved to archived and so the mirrormanager redirects.

I think maybe the MM redirects aren't working, while there won't be updates, it shouldn't error out either.

@jnsamyak wrote in https://forge.fedoraproject.org/releng/tickets/issues/13442#issuecomment-1071964: > Not sure what is the requirement here, when a release is EOL, there are no upgrades, and the release is moved to archived and so the mirrormanager redirects. I think maybe the MM redirects aren't working, while there won't be updates, it shouldn't error out either.
Author

Right, I would not expect any new updates post-EOL, but any existing updates that a user does not currently have (again, say they are bringing up a machine they haven't used for a while, etc) they should be able to update without errors and then perform a dnf system-upgrade.

I have a F42 machine here I need to update, and I could not reproduce the error, so I am not sure why that is. I'm also not sure how to test what MM is doing except indirectly via dnf.

Right, I would not expect any new updates post-EOL, but any existing updates that a user does not currently have (again, say they are bringing up a machine they haven't used for a while, etc) they should be able to update without errors and then perform a dnf system-upgrade. I have a F42 machine here I need to update, and I could not reproduce the error, so I am not sure why that is. I'm also not sure how to test what MM is doing except indirectly via dnf.
Owner

Yeah, I thought this was the mirrormanager metalink redirect not working, but it seems to be here. ;(

you can just look at the metalinks directly: 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64'

So, I wonder if that user modified things to not use metalink?

Yeah, I thought this was the mirrormanager metalink redirect not working, but it seems to be here. ;( you can just look at the metalinks directly: 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=x86_64' So, I wonder if that user modified things to not use metalink?
Author

They said they had swapped baseurl and metalink in fedora-updates.repo, but they undid it, verified the fedora-updates.repo was default, and did dnf clean all. It still kept failing. All being executed as root, so I don't think it was a wrong-user-seeing-cache type of issue, but sounds like it might have been cached in some way.

They said they had swapped baseurl and metalink in fedora-updates.repo, but they undid it, verified the fedora-updates.repo was default, and did dnf clean all. It still kept failing. All being executed as root, so I don't think it was a wrong-user-seeing-cache type of issue, but sounds like it might have been cached in some way.
Member

It could be a regional/routing thing, I have seen issues some times when in Australia.

It could be a regional/routing thing, I have seen issues some times when in Australia.
Author

Seems like this was perhaps user-specific, environment, regional, etc, not a general problem, so I am going to go ahead and close this. Thanks!

Seems like this was perhaps user-specific, environment, regional, etc, not a general problem, so I am going to go ahead and close this. Thanks!
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
releng/tickets#13442
No description provided.