F31 Repo Metadata 404

Discussions in English on using Fedora
#1

I have a Fedora 31 server that I set up not too long ago. When I try to install updates or install a new package today, this is what I see:

[root@gamma class]# dnf update
Fedora 31 - x86_64 - Updates                                                                                                                                                                                   47  B/s |  19  B     00:00    
Errors during downloading metadata for repository 'updates':
  - Status code: 404 for http://download.fedoraproject.org/pub/fedora/linux/updates/31/Everything/x86_64/repodata/repomd.xml (IP: 2605:bc80:3010:600:dead:beef:cafe:feda)
Error: Failed to download metadata for repo 'updates': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Indeed, http://download.fedoraproject.org/pub/fedora/linux/updates/31/Everything/x86_64/repodata/repomd.xml is 404. Walking up the filesystem tree, I noticed that https://download.fedoraproject.org/pub/fedora/linux/updates/31/ has a readme saying, “The contents of this directory have been moved to our archives …”.

Why is the updates repo broken so soon (I know F33 is out, but 31 isn’t really all that old) and (more importantly) how do I fix this so I can get the latest packages for this server? I know it’s been a while since updates were installed, so there should be at least a few updates pending. It’d also be nice to be able to install new packages, but this missing repo breaks dnf install too.

1 Like
#2

See also: "after life" repositories for EOL releases (32 bit F30) - #2 by vgaetera

2 Likes
#3

Right… I get that Fedora 32 and 33 are out, and that 31 has been EOL’d. But why should that break installing whatever remaining updates are needed? I want to get to the final set of packages for F31. It’s only been just over a month since it was EOL’d. Why is the repo broken already? How do I fix it so I can install a new package?

#4

Looks like the mirroring service has stopped serving this release, most likely due to EoL.

1 Like
#5

I managed to get this working by updating /etc/yum.repos.d/fedora-updates.repo. In the Updates repo, I changed the baseurl to includes the ‘archives’ address:

[updates]
name=Fedora $releasever - $basearch - Updates
baseurl=http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/$releasever/Everything/$basearch/

I had 271 packages needing updates, and I was then able to use dnf install again. It’s perfectly fine to EOL a release, but we shouldn’t be breaking dnf repos for existing installs… Shame.

1 Like
#6

Archiving the repositories is part of the EOL process. So it is perfectly fine.
And as far as I know it works in the same way in every distribution (at least CentOS and Ubuntu/Debian).
Think if every mirror around the world has to maintain gigabytes and gigabytes of packages related to every EOL system. Disk space is not free, and who offers a mirror (disk space and network bandwidth) do that on a voluntary basis.
So. Once you know that once a system is EOL you have to change the repository URL, that it is normal, there is nothing to complaint.

2 Likes
#7

It is common knowledge that fedora is on a set schedule and when EOL occurs for older versions. If you had a running version, did not keep it updated regularly, and were caught by surprise when the repo was archived then shame on you. Complaining about standard procedures is not right when you were at fault for not keeping up to date.

Should all the repos for all the past versions be kept active because “someone might be running that version”? I think not. If you want LTS support then switch to a distro that does provide LTS. Debian and Ubuntu come to mind.

1 Like
#8

For ~1 month? Yes For decades? Perhaps not.

I missed the EOL deadline and therefore had to go on an hour-long goose chase to figure out how to make dnf install foo and dnf update work again. That’s a really bad experience.

I don’t expect on-going security patches (LTS), but I do expect dnf install SomePackage to continue functioning. At minimum, we should provide a better error message than just a 404 (maybe a default dnf plugin could handle printing a helpful message after the EOL date). Or perhaps a final package could be left on the mirrors to install an “archives” repo and disable the broken repos. Something… Anything would be better than suddenly breaking with no info as to why/what/how.

Debian (and Ubuntu, because it’s really just Debian) put files in really weird places. I end up on goose-chases there just to find simple things because they decided to move them (seemingly for no particular reason other than to introduce confusion). My muscle memory is too used to the Red Hat-esque layout. Those are a no-go.

#9

I’ll also note that the broken repos prevent the published upgrade steps from working too, so I can’t upgrade from the EOL’d version even if I wanted to.

The dnf upgrade --refresh and dnf install dnf-plugin-system-upgrade commands (from this upgrade doc) are both broken.

Seems like some sort of grace period would be useful for keeping the upgrade path working/available after a release has become EOL’d.

#10

What error do you get? Didn’t you write that dnf update and dnf install are now working? upgrade and update is the same. dnf-plugin-system-upgrade is a package like others.
As far as I know it is possible to upgrade EOL releases, taking into account that only n+2 is supported (i.e. 30->32)

#11

As has been mentioned hardcoding your .repo file to point to the archive repo should have worked and you should be able to do anything you would have done as far as installing or upgrading packages for that version (F31).

I suspect and you have confirmed that the change you made allowed the “upgrade --refresh” to complete.
However, you likely will have to reset the .repo file to the original to do the “system-upgrade download” step if you are doing the upgrade to either 32 or 33 because those are the active repos and need the metadata called for by the original config to process the system upgrade step.
In other words, the upgrade required the archive repo, but the system-upgrade requires the active repo. The doc you linked to has a lot of info on how to handle various problem that you may see.

For future reference and to keep on track just remember that any release version is only active and supported until ~30 days after the release date of the +2 version. Information on that is here.

#12

Yes. I should clarify that they were both broken prior to my hard-coding the archives URL in the repo config. Had I not figured that out, there would have been no way to upgrade the system… It was giving the same 404 error as listed above, since it couldn’t fetch the repo metadata update, upgrade and installing dnf-plugin-system-upgrade were all completely broken.

1 Like
#13

So, now that you have configured the repositories, you are able to follow the upgrade steps, correct?