On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote: > Hello folks, > > With the retirement of modularity, the modular dnf repositories for Fedora 39 > no longer exist. However, this will introduce a problem during upgrades. When > users try to upgrade from previous Fedora releases with fedora-repos-modular > installed, they will hit fatal errors that will probably look like this: > > Errors during downloading metadata for repository 'fedora-modular': > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare > internal mirrorlist: Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > > Or: > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried > > (The actual error might differ depending on the exact state of the removal of > the modular repos and their mirrorlist etc.) > > > This is caused by the combination of the following facts: > > - the modular repo configuration in Fedora 37/38 has skip_if_unavailable=False > - when the releasever is set to 39, the URLs of the repos give error 404 > > This is a big deal, because even users who don't use modularity at all (but > have not uninstalled fedora-repos-modular) will not be able to upgrade to > Fedora 39+ without reaching for help. > > Adam outlined 3 options to solve this problem in the bugzilla where he reported > this: https://bugzilla.redhat.com/2228827 So an update to this, thanks to Miro for double-checking me: I had forgotten that the openQA tests edit the dnf config to point to the compose tree (in order to make sure we're testing the right thing - there's an ordering problem if we just test the actual 'rawhide' location on the mirror system, it might not have been synced by the time the tests run). It looks like the public 'rawhide' location *does* still have a Modular tree: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ but there's still a problem there, because...it's now just stale data. That is the Modular tree from the 20230802.n.0 compose, and unless someone does something about it, it always *will* be. Keeping the last set of modular repos frozen in amber forever doesn't seem like the best permanent situation :) So this is still an issue, but at least it doesn't actually immediately break upgrades to Rawhide using the default dnf config. I'll downgrade the bug severity appropriately. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
