Hello, So far I've upgraded three systems to F34 from F33 and two of them hit the same snag as clnetbox in https://bodhi.fedoraproject.org/updates/FEDORA-2021-377c35aa46 Both times I got this error when I ran dnf-plugin-system-upgrade: […] Error: Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-6.fc34.x86_64 and iptables-libs-1.8.7-3.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) I removed firewalld and iptables as suggested in https://bodhi.fedoraproject.org/updates/FEDORA-2021-377c35aa46#comment-1954030 (on one of the systems I hadn't installed the full libvirt stack yet - uninstalling it was necessary on the other one though) in order to complete the upgrade to F34. The third system that was unaffected was based on Cloud Edition, while the other two were installed from Workstation images. What's bugging me is that the Cloud VM had pretty much the same subset of iptables, firewalld and libvirt packages as one of the Workstation ones; looking at the dnf logs on each system I can't figure out what might have been different.
You need: https://bodhi.fedoraproject.org/updates/FEDORA-2021-377c35aa46 It just pushed out as a '0 day' update for f34. So, upgrades now should pick it up as soon as it's on the mirror network.
I am currently running another upgrade and the updated packages have been picked up. No issues during the transaction. There's another system that will have to wait until Monday, but it looks like it's solved. Thanks Kevin
I ran the other upgrades with all the *testing repos enabled, why wasn't it picked up then? It's been in testing for the last couple of weeks.
Not sure. I would have thought it would have been. ;(
Different system, the latest update gets picked up, but the error remains: # dnf --enablerepo=*testing --releasever=34 --allowerasing --best --skip-broken --refresh system-upgrade download […] Error: Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-6.fc34.x86_64 and iptables-libs-1.8.7-3.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository # rpm -qa | grep iptables iptables-libs-1.8.5-6.fc33.x86_64 iptables-1.8.5-6.fc33.x86_64 [root@OptiPlex aleplo]# rpm -qa | grep 'iptables\|libvirt\|firewall' libvirt-dbus-1.4.0-2.fc33.x86_64 libvirt-gconfig-3.0.0-3.fc33.x86_64 libvirt-glib-3.0.0-3.fc33.x86_64 libvirt-gobject-3.0.0-3.fc33.x86_64 python3-libvirt-6.6.0-1.fc33.x86_64 libvirt-libs-6.6.0-5.fc33.x86_64 libvirt-daemon-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-core-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-network-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-disk-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-gluster-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-iscsi-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-iscsi-direct-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-logical-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-mpath-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-rbd-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-scsi-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-sheepdog-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-zfs-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-interface-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-nodedev-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-nwfilter-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-secret-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-qemu-6.6.0-5.fc33.x86_64 libvirt-bash-completion-6.6.0-5.fc33.x86_64 libvirt-daemon-kvm-6.6.0-5.fc33.x86_64 libvirt-client-6.6.0-5.fc33.x86_64 libvirt-daemon-config-network-6.6.0-5.fc33.x86_64 python3-firewall-0.8.6-1.fc33.noarch firewalld-filesystem-0.8.6-1.fc33.noarch firewalld-0.8.6-1.fc33.noarch firewall-config-0.8.6-1.fc33.noarch iptables-libs-1.8.5-6.fc33.x86_64 iptables-1.8.5-6.fc33.x86_64
(In reply to Kevin Fenzi from comment #4) > Not sure. I would have thought it would have been. ;( Automatic push to stable was disabled due to the initial negative karma and it took me a while to realize that. Maybe that's why. (In reply to Alexander Ploumistos from comment #5) > Different system, the latest update gets picked up, but the error remains: > > # dnf --enablerepo=*testing --releasever=34 --allowerasing --best > --skip-broken --refresh system-upgrade download > > […] > Error: > Problem: cannot install the best update candidate for package > iptables-1.8.5-6.fc33.x86_64 > - problem with installed package iptables-1.8.5-6.fc33.x86_64 > - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = > 1.8.7-3.fc34, but none of the providers can be installed > - cannot install the best update candidate for package > iptables-libs-1.8.5-6.fc33.x86_64 > - cannot install both iptables-libs-1.8.7-6.fc34.x86_64 and > iptables-libs-1.8.7-3.fc34.x86_64 > - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository This is not conclusive to me: iptables-libs-1.8.7-6.fc34 seems available but not iptables-1.8.7-6.fc34? > # rpm -qa | grep iptables > iptables-libs-1.8.5-6.fc33.x86_64 > iptables-1.8.5-6.fc33.x86_64 > [root@OptiPlex aleplo]# rpm -qa | grep 'iptables\|libvirt\|firewall' Note that 'rpm -q' informs only about installed packages while you are interested in what is available for install (or not).
(In reply to Phil Sutter from comment #6) > > […] > > Error: > > Problem: cannot install the best update candidate for package > > iptables-1.8.5-6.fc33.x86_64 > > - problem with installed package iptables-1.8.5-6.fc33.x86_64 > > - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = > > 1.8.7-3.fc34, but none of the providers can be installed > > - cannot install the best update candidate for package > > iptables-libs-1.8.5-6.fc33.x86_64 > > - cannot install both iptables-libs-1.8.7-6.fc34.x86_64 and > > iptables-libs-1.8.7-3.fc34.x86_64 > > - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository > > This is not conclusive to me: iptables-libs-1.8.7-6.fc34 seems available but > not iptables-1.8.7-6.fc34? That's the weird part. I did a "dnf clean all" a couple of times with a 20-minute pause in between, but I always got the same result. I couldn't wait longer as this is my work computer and I needed to get working… > > # rpm -qa | grep iptables > > iptables-libs-1.8.5-6.fc33.x86_64 > > iptables-1.8.5-6.fc33.x86_64 > > [root@OptiPlex aleplo]# rpm -qa | grep 'iptables\|libvirt\|firewall' > > Note that 'rpm -q' informs only about installed packages while you are > interested in what is available for install (or not). Actually I wanted to list the installed packages, in case there's some interdependence, I didn't mean to copy the first command and its output. So far I've hit the issue in 3 out of 5 upgrades, I hope it's just me that's unlucky.
I'm seeing the same issue (upgrading from f33): > dnf system-upgrade download --refresh --releasever=34 --best --skip-broken Error: Problem: cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages)
Result of: > rpm -qa | grep 'iptables\|libvirt\|firewall' libvirt-gconfig-3.0.0-3.fc33.x86_64 libvirt-glib-3.0.0-3.fc33.x86_64 libvirt-gobject-3.0.0-3.fc33.x86_64 libvirt-libs-6.6.0-5.fc33.x86_64 libvirt-daemon-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-core-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-network-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-disk-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-gluster-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-iscsi-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-iscsi-direct-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-logical-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-mpath-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-rbd-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-scsi-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-sheepdog-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-zfs-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-storage-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-interface-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-nodedev-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-nwfilter-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-qemu-6.6.0-5.fc33.x86_64 libvirt-daemon-driver-secret-6.6.0-5.fc33.x86_64 libvirt-daemon-kvm-6.6.0-5.fc33.x86_64 libvirt-daemon-config-network-6.6.0-5.fc33.x86_64 python3-firewall-0.8.6-1.fc33.noarch firewalld-filesystem-0.8.6-1.fc33.noarch firewalld-0.8.6-1.fc33.noarch iptables-libs-1.8.5-6.fc33.x86_64 iptables-1.8.5-6.fc33.x86_64
@psutter Yes, it seems indeed like iptables-1.8.7-6 is missing from the updates repo. > dnf info iptables-libs --releasever=34 Name : iptables-libs Version : 1.8.7 Release : 6.fc34 Architecture : x86_64 Size : 402 k Source : iptables-1.8.7-6.fc34.src.rpm Repository : updates > dnf info iptables --releasever=34 Name : iptables Version : 1.8.7 Release : 3.fc34 Architecture : x86_64 Size : 109 k Source : iptables-1.8.7-3.fc34.src.rpm Repository : fedora While the package is present in the fedora repo (https://ftp.fau.de/fedora/linux/development/34/Everything/x86_64/os/Packages/i/) it is missing from the updates repo (https://ftp.fau.de/fedora/linux/updates/34/Everything/x86_64/Packages/i/) You can also clearly see that the 1.8.7-3 koji build (https://koji.fedoraproject.org/koji/buildinfo?buildID=1693272) still contains a iptables-1.8.7-3.fc34.x86_64.rpm while 1.8.7-4 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1724648) and later builds are all missing it. My guess would be that they got lost in this commit (https://src.fedoraproject.org/rpms/iptables/c/94169cfe5ba2ac03e85ecff7c8d32bc2642ccd59?branch=f34) where you removed the default '%files' and replaced it with sub-components. It looks like this breaks the upgrade process for a lot of people who don't know what to do - it would be great if you could clarify whether one should skip it or what upgrade flags to use. The issue is definitely not closed.
I see the problem here and know the fix. Basically nothing is pulling iptables.i686 into the x86_64 updates repo, so it's not there. I will fix it and push out a fixed repo today.
ok. This was not what I thought it was. The problem actually is iptables-1.8.7-3.fc34 in the base repo has a iptables binary package, but there's no iptables package in updates anymore (dropped in favor of iptables-compat, which should obsolete it) I am now not sure whats going on here... the iptables-compat in updates should obsolete the old iptables package. Those of you still seeing this with 'iptables-1.8.7-6.fc34' in your transaction, can you post the dnf output? I think some cases above were in fact that the update wasn't stable yet, but it is now and it looks to me like everything should work...
Seems I am affected by this issue too, here's my dnf output: > sudo dnf system-upgrade download --releasever=34 --best --allowerasing Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Docker CE Stable - x86_64 28 kB/s | 3.5 kB 00:00 Fedora 34 openh264 (From Cisco) - x86_64 1.5 kB/s | 989 B 00:00 Fedora Modular 34 - x86_64 23 kB/s | 18 kB 00:00 Fedora Modular 34 - x86_64 - Updates 9.3 kB/s | 21 kB 00:02 Fedora 34 - x86_64 - Updates 15 kB/s | 11 kB 00:00 Fedora 34 - x86_64 - Updates 183 kB/s | 436 kB 00:02 Fedora 34 - x86_64 8.4 kB/s | 18 kB 00:02 google-chrome 13 kB/s | 1.3 kB 00:00 RPM Fusion for Fedora 34 - Free - Updates 57 kB/s | 7.7 kB 00:00 RPM Fusion for Fedora 34 - Free 5.0 kB/s | 7.7 kB 00:01 RPM Fusion for Fedora 34 - Nonfree - Steam 4.9 kB/s | 7.9 kB 00:01 RPM Fusion for Fedora 34 - Nonfree - Updates 16 kB/s | 7.8 kB 00:00 RPM Fusion for Fedora 34 - Nonfree 15 kB/s | 7.8 kB 00:00 No match for group package "xorg-x11-drv-armsoc" No match for group package "khmeros-muol-fonts" No match for group package "powerpc-utils" No match for group package "khmeros-siemreap-fonts" No match for group package "khmeros-metal-chrieng-fonts" No match for group package "lsvpd" No match for group package "khmeros-battambang-fonts" No match for group package "khmeros-bokor-fonts" No match for group package "khmeros-handwritten-fonts" No match for group package "bcm283x-firmware" Error: Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) Just let me know if more info is required.
I just tried it and I get the same error, although some of the "No match" items are different: saf# dnf system-upgrade download --refresh --releasever=34 --best --allowerasing --skip-broken Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Fedora 34 openh264 (From Cisco) - x86_64 9.4 kB/s | 989 B 00:00 Fedora Modular 34 - x86_64 51 kB/s | 10 kB 00:00 Fedora Modular 34 - x86_64 - Updates 30 kB/s | 8.7 kB 00:00 Fedora 34 - x86_64 - Updates 73 kB/s | 9.8 kB 00:00 Fedora 34 - x86_64 - Updates 998 kB/s | 865 kB 00:00 Fedora 34 - x86_64 71 kB/s | 9.1 kB 00:00 google-chrome 15 kB/s | 1.3 kB 00:00 google-talkplugin 13 kB/s | 951 B 00:00 RPM Fusion for Fedora 34 - Free tainted 16 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 34 - Free - Updates 7.4 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 34 - Free 22 kB/s | 11 kB 00:00 RPM Fusion for Fedora 34 - Nonfree - Updates 7.5 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 34 - Nonfree 34 kB/s | 11 kB 00:00 No match for group package "k3b-extras-freeworld" No match for group package "uw-imap" No match for group package "plasma-user-manager" No match for group package "enemies-of-carlotta" No match for group package "powerpc-utils" No match for group package "isight-firmware-tools" No match for group package "amavisd-new" No match for group package "crypto-utils" No match for group package "cherokee" No match for group package "cockpit-kubernetes" No match for group package "lsvpd" No match for group package "moin" No match for group package "timedatex" No match for group package "Pound" No match for group package "bcm283x-firmware" No match for group package "cvsgraph" No match for group package "guestfs-browser" No match for group package "fedora-release-notes" No match for group package "dnf-yum" No match for group package "gobby" Error: Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository
Created attachment 1776181 [details] dnf.log with the failed transaction (In reply to Kevin Fenzi from comment #12) > > Those of you still seeing this with 'iptables-1.8.7-6.fc34' in your > transaction, can you post the dnf output? I think some cases above were in > fact that the update wasn't stable yet, but it is now and it looks to me > like everything should work... I have attached the excerpt from dnf.log on one of my systems from April 24, when iptables was still in testing. You'll notice the same mix-up with 1.8.7-3.fc34 and 1.8.7-6.fc34 Is dnf supposed to throw an exception when the depsolver can't figure out what to do?
I think the problem here is that iptables-compat doesn't Provides: iptables or anything like that, and nothing else Requires: iptables-compat . So I see no reason it would get pulled into the transaction at all. I don't think dnf/libsolv are expected to pull it in solely on the basis of the Obsoletes:, are they?
Same issue here: $ sudo dnf system-upgrade download --releasever=34 --allowerasing Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Fedora 34 openh264 (From Cisco) - x86_64 5.6 kB/s | 989 B 00:00 Fedora Modular 34 - x86_64 51 kB/s | 10 kB 00:00 Fedora Modular 34 - x86_64 - Updates 47 kB/s | 9.2 kB 00:00 Fedora 34 - x86_64 - Updates 41 kB/s | 7.0 kB 00:00 Fedora 34 - x86_64 - Updates 1.0 MB/s | 905 kB 00:00 Fedora 34 - x86_64 52 kB/s | 9.1 kB 00:00 RPM Fusion for Fedora 34 - Free - Updates 8.1 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 34 - Free 30 kB/s | 11 kB 00:00 RPM Fusion for Fedora 34 - Nonfree - Updates 8.4 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora 34 - Nonfree 23 kB/s | 11 kB 00:00 skype (stable) 7.6 kB/s | 2.9 kB 00:00 Visual Studio Code 8.8 kB/s | 3.0 kB 00:00 Windscribe 9.4 kB/s | 2.9 kB 00:00 No match for group package "xorg-x11-drv-armsoc" No match for group package "khmeros-metal-chrieng-fonts" No match for group package "gstreamer-plugins-good" No match for group package "WritRecogn" No match for group package "powerpc-utils" No match for group package "kranky-fonts" No match for group package "iok" No match for group package "senamirmir-washra-yigezu-bisrat-goffer-fonts" No match for group package "lsvpd" No match for group package "system-config-keyboard" No match for group package "scim-tables-additional" No match for group package "khmeros-siemreap-fonts" No match for group package "almas-mongolian-title-fonts" No match for group package "tabish-eeyek-fonts" No match for group package "monofett-fonts" No match for group package "google-noto-sans-balinese-fonts" No match for group package "inkboy-fonts" No match for group package "python2-scons" No match for group package "google-noto-sans-ui-fonts" No match for group package "senamirmir-washra-zelan-fonts" No match for group package "uim-canna" No match for group package "specialelite-fonts" No match for group package "impallari-lobster-fonts" No match for group package "xorg-x11-drv-omap" No match for group package "carterone-fonts" No match for group package "dnf-yum" No match for group package "gstreamer-plugins-bad" No match for group package "stix-math-fonts" No match for group package "senamirmir-washra-wookianos-fonts" No match for group package "reeniebeanie-fonts" No match for group package "chromium-libs-media-freeworld" No match for group package "totem-nautilus" No match for group package "tuladha-jejeg-fonts" No match for group package "kinput2" No match for group package "scim-chewing" No match for group package "google-croscore-tinos-fonts" No match for group package "smc-raghumalayalam-fonts" No match for group package "oflb-brett-fonts" No match for group package "isight-firmware-tools" No match for group package "min12xxw" No match for group package "tangerine-fonts" No match for group package "senamirmir-washra-fantuwua-fonts" No match for group package "fedora-release-notes" No match for group package "archmage" No match for group package "senamirmir-washra-hiwua-fonts" No match for group package "wallpoet-fonts" No match for group package "ht-alegreya-smallcaps-fonts" No match for group package "scim-array" No match for group package "scim-tables-chinese" No match for group package "mph-2b-damase-fonts" No match for group package "phetsarath-fonts" No match for group package "senamirmir-washra-yebse-fonts" No match for group package "senamirmir-washra-jiret-fonts" No match for group package "tharlon-fonts" No match for group package "xorg-x11-drv-geode" No match for group package "astloch-fonts" No match for group package "typemade-josefinsansstd-light-fonts" No match for group package "paratype-pt-sans-fonts" No match for group package "apanov-edrip-fonts" No match for group package "google-crosextra-carlito-fonts" No match for group package "google-droid-kufi-fonts" No match for group package "aldusleaf-crimson-text-fonts" No match for group package "khmeros-bokor-fonts" No match for group package "pagul-fonts" No match for group package "shadowsintolight-fonts" No match for group package "system-config-users" No match for group package "cvsgraph" No match for group package "oflb-icelandic-fonts" No match for group package "vt323-fonts" No match for group package "fedora-user-agent-chrome" No match for group package "khmeros-muol-fonts" No match for group package "cf-sorts-mill-goudy-fonts" No match for group package "gstreamer-plugins-bad-free" No match for group package "tlomt-orbitron-fonts" No match for group package "cyreal-wireone-fonts" No match for group package "trinity" No match for group package "oflb-sportrop-fonts" No match for group package "gstreamer-ffmpeg" No match for group package "khmeros-battambang-fonts" No match for group package "labelleaurore-fonts" No match for group package "libva-vaapi-driver" No match for group package "smc-kalyani-fonts" No match for group package "google-crosextra-caladea-fonts" No match for group package "senamirmir-washra-yigezu-bisrat-gothic-fonts" No match for group package "google-croscore-symbolneu-fonts" No match for group package "google-croscore-arimo-fonts" No match for group package "khmeros-handwritten-fonts" No match for group package "scim-tables-chinese-extra" No match for group package "google-croscore-cousine-fonts" No match for group package "moyogo-molengo-fonts" No match for group package "senamirmir-washra-tint-fonts" No match for group package "google-noto-mono-fonts" No match for group package "bcm283x-firmware" No match for group package "oflb-roadstencil-fonts" No match for group package "paratype-pt-sans-caption-fonts" No match for group package "gstreamer-plugins-ugly" No match for group package "bzr" No match for group package "trabajo-fonts" No match for group package "sarai-fonts" No match for group package "ecolier-court-lignes-fonts" Dependencies resolved. Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository
Hi, (In reply to Adam Williamson from comment #16) > I think the problem here is that iptables-compat doesn't Provides: iptables > or anything like that, and nothing else Requires: iptables-compat . So I see > no reason it would get pulled into the transaction at all. I don't think > dnf/libsolv are expected to pull it in solely on the basis of the > Obsoletes:, are they? In order to rename old iptables RPM into iptables-legacy, I followed the suggested process to rename or split packages illustrated here[1]. By Introducing a compat package which obsoletes the old name and requires the new name, dnf/yum should recognize the compat package as successor and install the actual successor as dependency. This has worked well in the past, e.g. with ebtables -> ebtables-legacy, I don't know what's happening here. [1] https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#.28n:m.29_Many_to_many_replacement
Just ran `dnf system-upgrade download --refresh --releasever=34 --allowerasing --best` on my working laptop and got same trace as in comment above, upgrade from F33 to F34 didn't work for me until I tried to uninstall iptables and firewalld
Perhaps at this point it would be a good idea to add this to the "Common F34 bugs" page on the wiki along with the workaround?
Kevin, (In reply to Kevin Fenzi from comment #12) > ok. This was not what I thought it was. > > The problem actually is iptables-1.8.7-3.fc34 in the base repo has a > iptables binary package, but there's no iptables package in updates anymore > (dropped in favor of iptables-compat, which should obsolete it) > > I am now not sure whats going on here... the iptables-compat in updates > should obsolete the old iptables package. Playing around on a F33 VM. Seems iptables-compat RPM is not even available, at least 'dnf search iptables-compat' doesn't list it. Can you quickly find out why that is?
(In reply to Phil Sutter from comment #21) > Kevin, > > (In reply to Kevin Fenzi from comment #12) > > ok. This was not what I thought it was. > > > > The problem actually is iptables-1.8.7-3.fc34 in the base repo has a > > iptables binary package, but there's no iptables package in updates anymore > > (dropped in favor of iptables-compat, which should obsolete it) > > > > I am now not sure whats going on here... the iptables-compat in updates > > should obsolete the old iptables package. > > Playing around on a F33 VM. Seems iptables-compat RPM is not even available, > at least 'dnf search iptables-compat' doesn't list it. Can you quickly find > out why that is? Ah, scratch that - it's obviously not present in F33. On F34, it is there, I can install it and Obsoletes/Requires lines seem correct.
Yeah, we need to add a 'Provides' for iptables to iptables-compat in order for it to get into the transaction. For some reason I was thinking of the fedora-obsolete-packages that magically doesn't need to be installed or anything to obsolete things. Can you make that update Phil? Or would you like me to?
Well, Phil's right that the guidelines don't show a Provides: . So either they're wrong, or it's actually intended that dnf/libsolv handles this. Looking into it a bit more, I see another potentially confounding factor. There's another subpackage - iptables-nft - which Provides: iptables . But iptables-compat doesn't depend on it, and neither does anything else. We also have several things in the distro that require, specifically, "iptables", e.g. firewalld. So put it together and this seems to be the state of play: 1. Many things require 'iptables' 2. In F33, there is an actual 'iptables' package, version 1.8.5-6.fc33 3. In F34 stable, there is an actual 'iptables' package, version 1.8.7-3.fc34 4. In F34 updates, there is no acutal 'iptables' package 5. In F34 updates, iptables-compat Obsoletes: iptables < 1.8.7-4 , but does not Provides: it 6. In F34 updates, iptables-nft Provides: iptables (unversioned), but nothing else seems to Requires: iptables-nft 7. In F34 updates, iptables-legacy Provides: iptables (unversioned), but nothing else seems to Requires: iptables-legacy This all seems a bit messy and I'm not that surprised it leads to unexpected outcomes, I guess. But I'm not sure what the "correct fix" would be. Let's CC some dnf/libsolv folks. BTW, I noticed that openQA tests actually encounter some version of this issue, but it is logged only as a warning and does not prevent the upgrade running. In a test which starts out as F33 with iptables, iptables-libs and iptables-nft installed, when upgrading to F34 with both 'fedora' and 'updates' repos enabled, the DNF logs show this: 2021-04-28T04:30:39-0400 WARNING Problem: cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 The upgrade ultimately installs iptables, iptables-libs and iptables-nft versions 1.8.7-3.fc34, and at the end of the transaction notes: Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): iptables-libs x86_64 1.8.7-6.fc34 updates 402 k So there seem to be different outcomes here possibly depending on what's installed at the start. Let's CC some dnf/libsolv folks to see if they can unpick this at all.
BTW, openQA even *actually caught this bug* when it initially tested the update: https://openqa.fedoraproject.org/tests/827226 that test failed because it checks after the main test has run that, if any package from the update is installed, the installed version is the version from the update. And when that test (the F33 to F34 upgrade test) ran, it was not, and so the test, correctly, failed. But for some reason that result does not show on the Bodhi page :( Possibly it didn't make it to resultsdb for some reason. I will try and check, if I can find the relevant logs.
...and I even commented on it at the time, but noted that if the update was pushed stable before release, the problem ought to go away. Unfortunately it wasn't.
(In reply to Adam Williamson from comment #24) > Well, Phil's right that the guidelines don't show a Provides: . So either > they're wrong, or it's actually intended that dnf/libsolv handles this. > > Looking into it a bit more, I see another potentially confounding factor. > There's another subpackage - iptables-nft - which Provides: iptables . But > iptables-compat doesn't depend on it, and neither does anything else. > > We also have several things in the distro that require, specifically, > "iptables", e.g. firewalld. > > So put it together and this seems to be the state of play: > > 1. Many things require 'iptables' > 2. In F33, there is an actual 'iptables' package, version 1.8.5-6.fc33 > 3. In F34 stable, there is an actual 'iptables' package, version 1.8.7-3.fc34 > 4. In F34 updates, there is no acutal 'iptables' package > 5. In F34 updates, iptables-compat Obsoletes: iptables < 1.8.7-4 , but does > not Provides: it > 6. In F34 updates, iptables-nft Provides: iptables (unversioned), but > nothing else seems to Requires: iptables-nft > 7. In F34 updates, iptables-legacy Provides: iptables (unversioned), but > nothing else seems to Requires: iptables-legacy Thanks for your analysis, Adam. Maybe the 'Provides: iptables' indeed confused dnf. Your assessment is not entirely correct, though: iptables-legacy has a 'Provides: iptables' as well. The goal is to have iptables-nft and iptables-legacy packages both providing 'iptables' (they are both alternative implementations and users may choose between them using alternatives). Therefore any dependency on 'iptables' ought to be fulfilled by either one of them. [...] > So there seem to be different outcomes here possibly depending on what's > installed at the start. Let's CC some dnf/libsolv folks to see if they can > unpick this at all. I can reproduce the problem only with the old 'iptables' package installed. F33 ships with iptables-nft as default, so this should affect "old" installations only. If I build all iptables RPMs from SRPM, call createrepo and add that to an F33 system, I can update iptables just fine and it pulls iptables-compat (and therefore iptables-legacy) as intended. So I am pretty clueless how to really reproduce the problem. I'll meanwhile add a provides line to iptables-compat, it shouldn't hurt. Hopefully this is at least a quick fix.
FEDORA-2021-aa7ad6f57f has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-aa7ad6f57f
I can confirm that the conflict disappears if I remove the old iptables package first. Since iptables-nft is installed this doesn't break any dependencies. My system is F33 but was installed as F32 in September 2020. While you try to fix it I guess it would make sense to add it to the common bugs (https://fedoraproject.org/wiki/Common_F34_bugs).
"Your assessment is not entirely correct, though: iptables-legacy has a 'Provides: iptables' as well." Er, yes? I did mention that. See points 6 and 7. "I'll meanwhile add a provides line to iptables-compat, it shouldn't hurt. Hopefully this is at least a quick fix." openQA tests should give us some idea whether that change fixes things, thanks. "I can confirm that the conflict disappears if I remove the old iptables package first" Yeah, but that can't be the only factor. In openQA testing, we have iptables installed on F33, and the upgrade logs a warning but runs (as I mentioned above). So for the upgrade to entirely bail out, there must be some other necessary factor.
Looks like it still doesn't work. openQA upgrade test failed for the same reason as before: the -7 builds don't get installed, the -3 builds get installed instead. We'll have to try and figure out why, I guess.
I was able to upgrade two machines here by leaving off the "--best" flag. I.e., I did: dnf system-upgrade download --releasever=34 --allowerasing and once the upgrade was complete, I did a "dnf update --refresh" and "dnf autoremove". Perhaps that should be listed in the "known bugs" as a workaround.
Well, how do you mean "leaving off"? The documentation does not recommend using it in the first place: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
Some of the previous comments to this bug (comment 5 and comment 13 for example) included --best. I also had --best in my notes, from previous upgrades, which is why I hit this bug. I don't remember why I had --best in my notes, but I did. I've since fixed my notes. :-) I did some searching and came across https://www.reddit.com/r/Fedora/comments/mznhey/unable_to_upgrade_to_fedora_34_iptables/ which said "leave out the --best" flag. I tried it, and it worked. So clearly, there are people who are having this problem, and mentioning the correct command in more places may help them out.
(In reply to Steven A. Falco from comment #34) > Some of the previous comments to this bug (comment 5 and comment 13 for > example) included --best. > > I also had --best in my notes, from previous upgrades, which is why I hit > this bug. I don't remember why I had --best in my notes, but I did. I've > since fixed my notes. :-) > > I did some searching and came across > https://www.reddit.com/r/Fedora/comments/mznhey/ > unable_to_upgrade_to_fedora_34_iptables/ which said "leave out the --best" > flag. I tried it, and it worked. > > So clearly, there are people who are having this problem, and mentioning the > correct command in more places may help them out. So when you did the system upgrade, you ended up with iptables version 3 and from there you were able to upgrade to version 6 (or 7) or are you still on version 3? (I suppose the machines that you were able to upgrade by leaving off the --best flag had encountered the error we're talking about)
so yeah, reproducing this in a VM and fiddling around a bit, it seems to fail if `--best` is passed (regardless of what else is passed; no use of `--allowerasing` or `--skip-broken` seems to change anything), and succeed but warn and use -3 instead of -6 or -7 if `--best` is not passed. I haven't figured out yet why it just will not go with the -6/-7 packages and respect the Obsoletes. BTW, a stock F33 install of Server has 'iptables' installed.
Aha, okay, I've got it. The problem is comps. The comps group 'networkmanager-submodules' lists the package 'iptables' specifically: <packagereq type="default">dnsmasq</packagereq> <!-- required for IPv4 connection sharing ("Hotspot") to work --> <packagereq type="default">iptables</packagereq> this is still there in F34 comps. dnf tries to respect installed groups on upgrade and make sure the packages they specify are all installed, and since there *is* an iptables package available, it wants to install it, even though it's obsoleted by something else. If you do `dnf group mark remove networkmanager-submodules` then try the upgrade again, it works without warnings (no --best) or errors (with --best), and pulls in the later iptables build (either -6 or -7, whichever you have available). I...am not sure we can actually fix this. The problem is that this 'iptables' entry in comps is now basically baked in, because it will always be in the frozen release comps data even if we update comps in git. When we update comps for a stable release, the comps data in the updates repo is regenerated (IIRC), but - again IIRC - dnf doesn't treat that as *overriding* the comps data in the base repo, exactly, it more sort of...combines them, I think. We may have to either just live with this and mention it in CommonBugs, or put the iptables package back in for F34 and delay this change to F35, along with updating comps. Unless anyone can think of something better.
I've been trying to figure this out on my end. So I've used the same command on all of the five systems I've upgraded: 1. Workstation, first version installed was F29 2. Workstation, first version installed was F30 3. Workstation, first version installed was F33 4. Mate spin (though maybe the spin didn't exist yet), first version installed was F20 5. Cloud image, first version installed was F27 Systems 1-3 triggered the error, no problems on 4 & 5. If understand correctly what you are saying, these last two didn't have the "networkmanager-submodules" group in their definition and that's why they were upgraded without a problem? I was stumped because 1 and 4 have pretty much the same user-installed packages and up to the comparison of 1 to 3 I was sure that the dependencies of virt-manager were to blame…
Yup, that would be my guess. The upgrade command does actually list out the group definitions it is trying to respect when upgrading, if you read carefully, and you can also use 'dnf group list' to see what groups are installed.
FEDORA-2021-aa7ad6f57f has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-aa7ad6f57f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-aa7ad6f57f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Adam Williamson from comment #37) > Aha, okay, I've got it. The problem is comps. > > The comps group 'networkmanager-submodules' lists the package 'iptables' > specifically: > > <packagereq type="default">dnsmasq</packagereq> > <!-- required for IPv4 connection sharing ("Hotspot") to work --> > <packagereq type="default">iptables</packagereq> > > this is still there in F34 comps. dnf tries to respect installed groups on > upgrade and make sure the packages they specify are all installed, and since > there *is* an iptables package available, it wants to install it, even > though it's obsoleted by something else. Thanks for clarifying this! Is there a way to have a softer dependency in there which accepts 'Provides:' lines? From my side, reverting the package name in F34 is fine if it avoids inconveniences for users but how can we prevent the same from happening in F34->F35 upgrades?
"Is there a way to have a softer dependency in there which accepts 'Provides:' lines?" More or less, no. comps is ancient and has always meant "a package called exactly this", IIRC. "how can we prevent the same from happening in F34->F35 upgrades?" change F35 comps *before* F35 is released. Now would be a good time. :D I would've sent a PR only I don't know what change would be appropriate exactly - i.e. what package we actually need to include these days for the relevant NetworkManager functionality to work.
Still an issue: Error: Problem: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository Workaround - temporarily removing iptables for the upgrade. dnf -y remove iptables after reboot to F34 install iptables from updates-testing dnf install iptables --enablerepo=updates-testing
You don't need to reinstall the package. It is not needed. An easier workaround is just not to use --best. See earlier comments for explanation why there is still an issue.
FEDORA-2021-aa7ad6f57f has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Sorry, I didn't get it and would like to ask again. For me removing iptables prior to updating didn't help, as it is a conflict with iptables-libs. Using --allowerasing (and not using --best) will skip iptables-libs. So that's correct?
It's working now... Let me put it together: "sudo dnf system-upgrade download --refresh --releasever=34 --allowerasing" was about to skip iptables-libs I removed iptables. Now it's upgrading with "sudo dnf system-upgrade download --refresh --releasever=34 --allowerasing --best" without skipping anything. Afaik iptables-libs is still needed so removing iptables prior to running the upgrade is better than running the upgrade with --allowerasing and skipping iptables-libs, isn't it?
(In reply to Daniel Laczi from comment #47) > It's working now... Let me put it together: > > "sudo dnf system-upgrade download --refresh --releasever=34 --allowerasing" > was about to skip iptables-libs > I removed iptables. > Now it's upgrading with "sudo dnf system-upgrade download --refresh > --releasever=34 --allowerasing --best" without skipping anything. > > Afaik iptables-libs is still needed so removing iptables prior to running > the upgrade is better than running the upgrade with --allowerasing and > skipping iptables-libs, isn't it? Although I was never able to reproduce the problem, I think consensus was the system-upgrade would skip iptables update and the next regular 'dnf update' would then make up for it. So there should not be a need to remove iptables package.
https://fedoraproject.org/wiki/Common_F34_bugs#iptables-upgrade-best
We changed comps via https://bugzilla.redhat.com/show_bug.cgi?id=1957346 / https://pagure.io/fedora-comps/pull-request/655 , so I think everything that can be done here has been done. Closing.