$ sudo docker run --rm -it registry.fedoraproject.org/fedora:rawhide /bin/sh
sh-4.4# sh-4.4# dnf upgrade
Last metadata expiration check: 0:02:21 ago on Thu Apr 12 15:02:35 2018.
Traceback (most recent call last):
File "/usr/bin/dnf", line 58, in <module>
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 179, in user_main
errcode = main(args)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 115, in cli_run
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 1015, in run
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 768, in _process_demands
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 454, in fill_sack
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 217, in _setup_modules
module_metadata = ModuleMetadataLoader(repo).load()
File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 53, in load
File "/usr/lib/python3.6/site-packages/modulemd/__init__.py", line 99, in loads_all
File "/usr/lib/python3.6/site-packages/modulemd/__init__.py", line 229, in loadd
raise ValueError("The supplied metadata version isn't supported")
ValueError: The supplied metadata version isn't supported
sh-4.4# rpm -q dnf
As a workaround, I can disable the modular repo:
# dnf upgrade --disablerepo rawhide-modular
This is probably problem of metadata. I suspect that on rawhide module metadata are in v2, which is not supported by dnf-2.7.5-8. Try updating dnf to dnf-2.7.5-9 or newer.
Yes, this is because the latest DNF in F28 doesn't support v2.
I created an update for dnf-2.7.5-9 yesterday so that people don't have to download it from koji but this is probably going to bite many.
I have encountered the same issue starting with the docker image "docker.io/fedora:28". "dnf update" followed by "dnf install fedora-repos-modular" works fine. "dnf install fedora-repos-modular" followed by "dnf update" explodes with the exception shown in the description above.
could the update also include an updated fedora-repos-modular which requires the updated dnf, to avoid fresh installs possibly falling into the same trap as Merlin hit? Does that make sense?
This actually seems to affect simply booting an install of current Fedora Server 28 and running 'dnf' - it broke multiple openQA tests today:
so obviously +1 blocker.
dnf-2.7.5-9.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-6aacf0bd62
+1 blocker per comment 6.
dnf-2.7.5-9.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
fwiw, workaround that worked for me
# cat /tmp/bz1566593-workaround.sh
for f in https://kojipkgs.fedoraproject.org//packages/dnf/2.7.5/9.fc28/noarch/python3-dnf-2.7.5-9.fc28.noarch.rpm https://kojipkgs.fedoraproject.org//packages/dnf/2.7.5/9.fc28/noarch/dnf-2.7.5-9.fc28.noarch.rpm https://kojipkgs.fedoraproject.org//packages/dnf/2.7.5/9.fc28/noarch/dnf-automatic-2.7.5-9.fc28.noarch.rpm https://kojipkgs.fedoraproject.org//packages/dnf/2.7.5/9.fc28/noarch/dnf-conf-2.7.5-9.fc28.noarch.rpm https://kojipkgs.fedoraproject.org//packages/dnf/2.7.5/9.fc28/noarch/dnf-yum-2.7.5-9.fc28.noarch.rpm https://kojipkgs.fedoraproject.org//packages/libmodulemd/1.4.1/1.fc28/x86_64/libmodulemd-1.4.1-1.fc28.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/pyliblzma/0.5.3/21.fc28/x86_64/pyliblzma-0.5.3-21.fc28.x86_64.rpm; do wget $f; done
dnf --disablerepo=* install -y *.rpm