Hi,
I had an enforced "not able to upgrade Fedora Rawhide for too long" period. On doing the updates, one of my four computers updated fine, the other three however got into problems. They are now in a state where "dnf check-updates" reports a number of obsoletes, but "dnf upgrade" says nothing to do, and "dnf check" reports 2000+ duplicates. I am certain someone in the past told me how to get out of this as I am fairly sure I had a not dissimilar situation early last year. However, I cannot find the email that I am sure I kept somewhere.
In desperation I tried "dnf remove --duplicates" and after downloading 2.3GB it reports large numbers of dependency fails and does nothing.
I am confident there must be a way of solving this short of re-installation, hopefully someone knows the magic I need to fix these three computers.
On Sun, 05 Aug 2018 10:50:09 +0100 Russel Winder russel@winder.org.uk wrote:
Hi,
I had an enforced "not able to upgrade Fedora Rawhide for too long" period. On doing the updates, one of my four computers updated fine, the other three however got into problems. They are now in a state where "dnf check-updates" reports a number of obsoletes, but "dnf upgrade" says nothing to do, and "dnf check" reports 2000+ duplicates. I am certain someone in the past told me how to get out of this as I am fairly sure I had a not dissimilar situation early last year. However, I cannot find the email that I am sure I kept somewhere.
In desperation I tried "dnf remove --duplicates" and after downloading 2.3GB it reports large numbers of dependency fails and does nothing.
I am confident there must be a way of solving this short of re-installation, hopefully someone knows the magic I need to fix these three computers.
I think you want to see what the issues are. Do dnf --best update 2> dnf_errors.txt and look at the output file. It is kind of like a log jam. There are probably a few key packages that are orphaned, and they depend on older libraries that are common to many other packages. Once they are removed, the logjam will resolve itself. Using this technique allows you to manually determine whether the updates are more important than a package you have installed that is blocking the update.
If you use dnf --best --allowerasing update it will remove anything that blocks updates, but that can be a lot of packages, some of which you might want to keep. You can use the dnf logs in /var/log to re-install packages that have been removed that you want to still have installed. Sometimes this fails because a version that works with the updated libraries is not available, though.
On Sun, 2018-08-05 at 06:23 -0700, stan wrote:
[…]
I think you want to see what the issues are. Do dnf --best update 2> dnf_errors.txt and look at the output file. It is kind of like a log jam. There are probably a few key packages that are orphaned, and they depend on older libraries that are common to many other packages. Once they are removed, the logjam will resolve itself. Using this technique allows you to manually determine whether the updates are more important than a package you have installed that is blocking the update.
There are no errors!
[root@anglides ~]# dnf check-update --refresh bintray--pony-language-pony-stable-rpm 8.0 kB/s | 1.3 kB 00:00 bintray--pony-language-ponyc-rpm 7.7 kB/s | 1.3 kB 00:00 Crystal 1.9 kB/s | 2.9 kB 00:01 Fedora - Modular Rawhide - Developmental packag 37 kB/s | 20 kB 00:00 Fedora - Rawhide - Developmental packages for t 24 kB/s | 2.3 kB 00:00 local 110 kB/s | 3.0 kB 00:00 RPM Fusion for Fedora Rawhide - Free 83 kB/s | 11 kB 00:00 RPM Fusion for Fedora Rawhide - Nonfree 27 kB/s | 11 kB 00:00 Vivaldi Browser 82 kB/s | 2.9 kB 00:00 Last metadata expiration check: 0:00:00 ago on Sun 05 Aug 2018 16:10:08 BST. Obsoleting Packages grub2-tools.x86_64 1:2.02- 46.fc29 @rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools.x86_64 1:2.02- 46.fc29 rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-efi.x86_64 1:2.02- 46.fc29 @rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-efi.x86_64 1:2.02- 46.fc29 rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-extra.x86_64 1:2.02- 46.fc29 @rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-extra.x86_64 1:2.02- 46.fc29 rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-minimal.x86_64 1:2.02- 46.fc29 @rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System grub2-tools-minimal.x86_64 1:2.02- 46.fc29 rawhide grub2-tools.x86_64 1:2.02- 37.fc29 @System libmodulemd.i686 1.6.1- 2.fc29 rawhide python2-modulemd.noarch 1.3.3- 2.fc29 @System libmodulemd.x86_64 1.6.1- 2.fc29 @rawhide python2-modulemd.noarch 1.3.3- 2.fc29 @System libmodulemd.x86_64 1.6.1- 2.fc29 rawhide python2-modulemd.noarch 1.3.3- 2.fc29 @System nss-pem.x86_64 1.0.3- 10.fc29 @rawhide nss-pem.x86_64 1.0.3- 9.fc29 @System nss-pem.x86_64 1.0.3- 10.fc29 rawhide nss-pem.x86_64 1.0.3- 9.fc29 @System redhat-lsb-printing.i686 4.1- 45.fc29 rawhide redhat-lsb-printing.x86_64 4.1- 44.fc28 @System redhat-lsb-printing.x86_64 4.1- 45.fc29 @rawhide redhat-lsb-printing.x86_64 4.1- 44.fc28 @System redhat-lsb-printing.x86_64 4.1- 45.fc29 rawhide redhat-lsb-printing.x86_64 4.1- 44.fc28 @System wireless-regdb.noarch 2018.05.31- 3.fc29 rawhide crda.x86_64 3.18_2018.05.31- 1.fc29 @System
[root@anglides ~]# dnf upgrade --best Last metadata expiration check: 0:00:41 ago on Sun 05 Aug 2018 16:10:08 BST. Dependencies resolved. Nothing to do. Complete!
[root@anglides ~]# dnf check … zsh-5.5.1-1.fc29.x86_64 is a duplicate with zsh-5.5.1-2.fc29.x86_64 zvbi-0.2.35-5.fc28.x86_64 is a duplicate with zvbi-0.2.35-6.fc29.x86_64 zziplib-0.13.68-2.fc29.x86_64 is a duplicate with zziplib-0.13.69- 1.fc29.x86_64 Error: Check discovered 2242 problem(s)
[…]
On Sun, 05 Aug 2018 16:15:19 +0100 Russel Winder russel@winder.org.uk wrote:
[snip]
[root@anglides ~]# dnf upgrade --best Last metadata expiration check: 0:00:41 ago on Sun 05 Aug 2018 16:10:08 BST. Dependencies resolved. Nothing to do. Complete!
[root@anglides ~]# dnf check … zsh-5.5.1-1.fc29.x86_64 is a duplicate with zsh-5.5.1-2.fc29.x86_64 zvbi-0.2.35-5.fc28.x86_64 is a duplicate with zvbi-0.2.35-6.fc29.x86_64 zziplib-0.13.68-2.fc29.x86_64 is a duplicate with zziplib-0.13.69- 1.fc29.x86_64 Error: Check discovered 2242 problem(s)
I recently saw this with a package in F28. This shouldn't happen, as far as I know, because the later package is replacing the earlier package and dnf should know that. My take is that some change to the package gives the later version a different signature, so that dnf actually thinks they are different packages, but that is just a guess. I resolved the issue by running, for your case, dnf -x zsh -x zvbi -x zziplib upgrade After that completed, I did dnf remove zsh zvbi zziplib dnf install zsh zvbi zziplib In my case, the package was a leaf package, so this was trivial. If your packages have a lot of dependencies, all those will be taken out by the remove, and will have to be installed along with zsh, zvbi, and zziplib. Some of them might not be available for the new version.
On Sun, 2018-08-05 at 10:22 -0700, stan wrote: […]
I recently saw this with a package in F28. This shouldn't happen, as far as I know, because the later package is replacing the earlier package and dnf should know that. My take is that some change to the package gives the later version a different signature, so that dnf actually thinks they are different packages, but that is just a guess. I resolved the issue by running, for your case, dnf -x zsh -x zvbi -x zziplib upgrade After that completed, I did dnf remove zsh zvbi zziplib dnf install zsh zvbi zziplib In my case, the package was a leaf package, so this was trivial. If your packages have a lot of dependencies, all those will be taken out by the remove, and will have to be installed along with zsh, zvbi, and zziplib. Some of them might not be available for the new version.
I tried "dnf remove --duplicates" but that downloaded 2.3GB and then failed to do anything due to dependency failures.
Pragmatically I am not sure can try your suggestion as actually there are 2242 problem packages not just three. :-(
On Sun, 2018-08-05 at 18:48 +0100, Russel Winder wrote:
[…]
I tried "dnf remove --duplicates" but that downloaded 2.3GB and then failed to do anything due to dependency failures.
Pragmatically I am not sure can try your suggestion as actually there are 2242 problem packages not just three. :-(
On the other hand it seems that the output of "dnf check" can be piped through "grep 'is a duplicate with'" and awk to select the first column which is the name of the package that is being replaced so it can go into a "xargs dnf remove" assuming dnf can take 2000+ arguments.
I had assumed this is what "dnf remove --duplicates" would do, but it doesn't.
Except of course that the packages sudo, systemd, and systemd-udev are protected and you cannot do "dnf remove" on them even if you are removing a duplicate :-(
On Sun, 2018-08-05 at 19:23 +0100, Russel Winder wrote:
On Sun, 2018-08-05 at 18:48 +0100, Russel Winder wrote:
[…]
I tried "dnf remove --duplicates" but that downloaded 2.3GB and then failed to do anything due to dependency failures.
Pragmatically I am not sure can try your suggestion as actually there are 2242 problem packages not just three. :-(
On the other hand it seems that the output of "dnf check" can be piped through "grep 'is a duplicate with'" and awk to select the first column which is the name of the package that is being replaced so it can go into a "xargs dnf remove" assuming dnf can take 2000+ arguments.
I had assumed this is what "dnf remove --duplicates" would do, but it doesn't.
By judicious used of dnf, grep, and awk, I am now down to:
[root@anglides ~]# dnf check-update Last metadata expiration check: 0:00:28 ago on Sun 05 Aug 2018 19:57:06 BST. [root@anglides ~]# dnf check sudo-1.8.23-1.fc29.x86_64 is a duplicate with sudo-1.8.23-3.fc29.x86_64 systemd-239-1.fc29.x86_64 is a duplicate with systemd-239-3.fc29.x86_64 systemd-container-239-1.fc29.x86_64 is a duplicate with systemd- container-239-3.fc29.x86_64 systemd-devel-239-1.fc29.x86_64 is a duplicate with systemd-devel-239- 3.fc29.x86_64 systemd-libs-239-1.fc29.x86_64 is a duplicate with systemd-libs-239- 3.fc29.x86_64 systemd-pam-239-1.fc29.x86_64 is a duplicate with systemd-pam-239- 3.fc29.x86_64 systemd-udev-239-1.fc29.x86_64 is a duplicate with systemd-udev-239- 3.fc29.x86_64 Error: Check discovered 7 problem(s)
but I have no idea if stuff is actually internally self consistent.
On Sun, 05 Aug 2018 19:59:55 +0100 Russel Winder russel@winder.org.uk wrote:
By judicious used of dnf, grep, and awk, I am now down to:
[root@anglides ~]# dnf check-update Last metadata expiration check: 0:00:28 ago on Sun 05 Aug 2018 19:57:06 BST. [root@anglides ~]# dnf check sudo-1.8.23-1.fc29.x86_64 is a duplicate with sudo-1.8.23-3.fc29.x86_64 systemd-239-1.fc29.x86_64 is a duplicate with systemd-239-3.fc29.x86_64 systemd-container-239-1.fc29.x86_64 is a duplicate with systemd- container-239-3.fc29.x86_64 systemd-devel-239-1.fc29.x86_64 is a duplicate with systemd-devel-239- 3.fc29.x86_64 systemd-libs-239-1.fc29.x86_64 is a duplicate with systemd-libs-239- 3.fc29.x86_64 systemd-pam-239-1.fc29.x86_64 is a duplicate with systemd-pam-239- 3.fc29.x86_64 systemd-udev-239-1.fc29.x86_64 is a duplicate with systemd-udev-239- 3.fc29.x86_64 Error: Check discovered 7 problem(s)
but I have no idea if stuff is actually internally self consistent.
You can, of course, use rpm directly to force install of these rpms. But the fact that this is such a large problem leads me to think there is a bug in some fundamental part of the update chain. As you say, there is no way to know if things are consistent at this point. Would the replacements function as well as the originals if you did force install them? If you are experimenting on only one system, and you do go the force install route, you might want to hold off on updating the other systems for a while to see if this is fixed in newer updates. There must be other people experiencing this problem.
Really strange.
On 08/05/2018 02:50 AM, Russel Winder wrote:
I had an enforced "not able to upgrade Fedora Rawhide for too long" period. On doing the updates, one of my four computers updated fine, the other three however got into problems. They are now in a state where "dnf check-updates" reports a number of obsoletes, but "dnf upgrade" says nothing to do, and "dnf check" reports 2000+ duplicates. I am certain someone in the past told me how to get out of this as I am fairly sure I had a not dissimilar situation early last year. However, I cannot find the email that I am sure I kept somewhere.
I have no idea why you have so many duplicates. That usually happens when the update process gets interrupted part way through. Try running "dnf distro-sync".
On Sun, 2018-08-05 at 16:10 -0700, Samuel Sieb wrote: […]
I have no idea why you have so many duplicates. That usually happens when the update process gets interrupted part way through. Try running "dnf distro-sync".
[…]
[root@lionors ~]# dnf distro-sync Last metadata expiration check: 0:01:08 ago on Mon 06 Aug 2018 20:38:26 BST. Error: Problem: The operation would result in removing the following protected packages: sudo, systemd, systemd-udev
:-(
On Mon, 2018-08-06 at 20:42 +0100, Russel Winder wrote:
On Sun, 2018-08-05 at 16:10 -0700, Samuel Sieb wrote: […]
I have no idea why you have so many duplicates. That usually happens when the update process gets interrupted part way through. Try running "dnf distro-sync".
[…]
[root@lionors ~]# dnf distro-sync Last metadata expiration check: 0:01:08 ago on Mon 06 Aug 2018 20:38:26 BST. Error: Problem: The operation would result in removing the following protected packages: sudo, systemd, systemd-udev
:-(
So I tried:
[root@lionors ~]# dnf distro-sync -x sudo -x systemd -x systemd-udev Last metadata expiration check: 0:04:24 ago on Mon 06 Aug 2018 20:38:26 BST. Dependencies resolved. ====================================================================================== Package Arch Version Repository Size ====================================================================================== Removing dependent packages: systemd x86_64 239-1.fc29 @System 11 M systemd-container x86_64 239-1.fc29 @System 1.1 M systemd-devel x86_64 239-1.fc29 @System 295 k systemd-libs x86_64 239-1.fc29 @System 1.7 M systemd-pam x86_64 239-1.fc29 @System 372 k systemd-udev x86_64 239-1.fc29 @System 7.5 M Downgrading: dtv-scan-tables noarch 1-2.20171226git07b18ecef174.fc29 rawhide 565 k dtv-scan-tables-legacy noarch 1-2.20171226git07b18ecef174.fc29 rawhide 230 k librados2 x86_64 1:12.2.6-1.fc29 rawhide 3.0 M
Transaction Summary ====================================================================================== Remove 6 Packages Downgrade 3 Packages
Total download size: 3.8 M Is this ok [y/N]: y Downloading Packages: (1/3): dtv-scan-tables-legacy-1-2.20171226git07b18ece 166 kB/s | 230 kB 00:01 (2/3): dtv-scan-tables-1-2.20171226git07b18ecef174.fc 385 kB/s | 565 kB 00:01 (3/3): librados2-12.2.6-1.fc29.x86_64.rpm 1.3 MB/s | 3.0 MB 00:02 -------------------------------------------------------------------------------------- Total 1.7 MB/s | 3.8 MB 00:02 /usr/lib/python3.7/site-packages/dnf/cli/cli.py:231: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working if not isinstance(display, collections.Sequence):
Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: librados2-1:12.2.6-1.fc29.x86_64 1/1 Downgrading : librados2-1:12.2.6-1.fc29.x86_64 1/12 Downgrading : dtv-scan-tables-legacy-1-2.20171226git07b18ecef174.fc29. 2/12 Downgrading : dtv-scan-tables-1-2.20171226git07b18ecef174.fc29.noarch 3/12 Erasing : systemd-devel-239-1.fc29.x86_64 4/12 Cleanup : dtv-scan-tables-legacy-1-8.20161007git0b42d8e8b44e.fc28. 5/12 Cleanup : dtv-scan-tables-1-8.20161007git0b42d8e8b44e.fc28.noarch 6/12 Running scriptlet: systemd-udev-239-1.fc29.x86_64 7/12 Erasing : systemd-udev-239-1.fc29.x86_64 7/12 Running scriptlet: systemd-udev-239-1.fc29.x86_64 7/12 Erasing : systemd-container-239-1.fc29.x86_64 8/12 Erasing : systemd-pam-239-1.fc29.x86_64 9/12 Running scriptlet: systemd-239-1.fc29.x86_64 10/12 Erasing : systemd-239-1.fc29.x86_64 10/12 Erasing : systemd-libs-239-1.fc29.x86_64 11/12 Cleanup : librados2-1:12.2.7-1.fc29.x86_64 12/12 Running scriptlet: librados2-1:12.2.7-1.fc29.x86_64 12/12 Verifying : dtv-scan-tables-1-2.20171226git07b18ecef174.fc29.noarch 1/12 Verifying : dtv-scan-tables-1-8.20161007git0b42d8e8b44e.fc28.noarch 2/12 Verifying : dtv-scan-tables-legacy-1-2.20171226git07b18ecef174.fc29. 3/12 Verifying : dtv-scan-tables-legacy-1-8.20161007git0b42d8e8b44e.fc28. 4/12 Verifying : librados2-1:12.2.6-1.fc29.x86_64 5/12 Verifying : librados2-1:12.2.7-1.fc29.x86_64 6/12 Verifying : systemd-239-1.fc29.x86_64 7/12 Verifying : systemd-container-239-1.fc29.x86_64 8/12 Verifying : systemd-devel-239-1.fc29.x86_64 9/12 Verifying : systemd-libs-239-1.fc29.x86_64 10/12 Verifying : systemd-pam-239-1.fc29.x86_64 11/12 Verifying : systemd-udev-239-1.fc29.x86_64 12/12
Downgraded: dtv-scan-tables-1-2.20171226git07b18ecef174.fc29.noarch dtv-scan-tables-legacy-1-2.20171226git07b18ecef174.fc29.noarch librados2-1:12.2.6-1.fc29.x86_64
Removed: systemd-239-1.fc29.x86_64 systemd-container-239-1.fc29.x86_64 systemd-devel-239-1.fc29.x86_64 systemd-libs-239-1.fc29.x86_64 systemd-pam-239-1.fc29.x86_64 systemd-udev-239-1.fc29.x86_64
Complete! [root@lionors ~]# dnf check-update Last metadata expiration check: 0:05:53 ago on Mon 06 Aug 2018 20:38:26 BST. [root@lionors ~]# dnf upgrade Last metadata expiration check: 0:06:00 ago on Mon 06 Aug 2018 20:38:26 BST. Dependencies resolved. Nothing to do. Complete! [root@lionors ~]# dnf check sudo-1.8.23-1.fc29.x86_64 is a duplicate with sudo-1.8.23-3.fc29.x86_64 Error: Check discovered 1 problem(s)
Which I think has to come under the heading weird.
On 08/06/2018 12:48 PM, Russel Winder wrote:
[root@lionors ~]# dnf check sudo-1.8.23-1.fc29.x86_64 is a duplicate with sudo-1.8.23-3.fc29.x86_64 Error: Check discovered 1 problem(s)
Which I think has to come under the heading weird.
I agree. Why did it erase the systemd packages? But at least it is mostly fixed now. I expect it will be resolved on the next sudo update. Shouldn't be a problem for now.