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.
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?
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:
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.
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.
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.
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.
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.
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)
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.
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.