Current Fedora Rawhide installer image composes are rather broken because they contain fedora-modular-release and fedora-modular-repos , not fedora-release and fedora-repos . This causes them to try and use a non-existent repository and fail to be able to set up packaging at all. This changed between Fedora-Rawhide-20180212.n.0 and Fedora-Rawhide-20180213.n.0 (though we didn't notice till today as both those composes, and all between 20180204.n.0 and 20180218.n.0, ultimately failed entirely for other reasons). https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180212.n.0/logs/x86_64/buildinstall-Everything.x86_64.log https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180213.n.0/logs/x86_64/buildinstall-Everything.x86_64.log Those are the 'Everything' buildinstall logs for the two composes in question (the logs for other variants are similar). Note that in 20180212.n.0 'fedora-release', 'fedora-repos' and 'fedora-repos-rawhide' are installed, but in 20180213.n.0, 'fedora-modular-release' and 'fedora-modular-repos' are installed (there is no 'fedora-modular-repos-rawhide'). I made a diff of all the packages between those two composes. There are quite a lot as it was in the middle of the mass rebuild, but one obvious suspect leaps out: dnf-2.7.5-8.fc28 . The changelog for that build says: * Mon Feb 12 2018 Daniel Mach <dmach> - 2.7.5-8 - Rebase to dnf from dnf-2-modularity branch. so this certainly looks like it could be the cause. I *suspect* that ultimately nothing in the package set pulled in by lorax during these image composes specifically requires fedora-release; instead there is at least one package (setup - there may be others too) that requires system-release. system-release is provided by fedora-release, fedora-modular-release and generic-release, so we're relying on dnf to pick 'the right one' there, somehow. I think something in the 'dnf-2-modularity' branch causes it to prefer fedora-modular-release to satisfy that requirement where previously it preferred fedora-release. That is only my suspicion, though, there may be some other explanation. Proposing as a Fedora 28 Beta blocker, as a violation of "...Release-blocking network install images must default to a valid publicly-accessible package source." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_package_sources . This is violated for the Everything network install image, which does not do that any more.
BTW, it occurs to me to wonder whether fedora-modular-release should actually exist at all any more, with the new Modularity plan: https://fedoraproject.org/wiki/Changes/F28AddonModularity
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
it does not need to exist in the new world, I have retired it
The fedora-modular-release was probably picked by depsolver. You need to specify fedora-release manually if you want to include it as a priority package. I don't think this is a bug.
Well, it's not entirely that simple, but in any case, we solved this a different way: the package has been retired. I've verified that recent composes are back to using fedora-release and fedora-repos.