Created attachment 1027037 [details] corpus delicti I did the following: - dnf install alacarte - dnf remove alacarte What happened: dnf removed alacarte. AND dnf autoremoved zlib(!) and sqlite - which results in an utterly unusable and broken system. I could only repair it from another install of fedora on a seperate partition. Might this problem be a leftover of the rpm package dependency generation bug I read about? If this also happens in the background when removing software in gnome-software, it would be disastrous for most users (system is unrecoverably broken without seperate linux install). Version-Release number of selected component (if applicable): rpm-4.12.0.1-9.fc22.x86_64 dnf-1.0.0-1.fc22.noarch How reproducible: Not sure, sometimes just happens when removing installed applications (happened for firefox once, and then for alacarte)
Thanks for the report. First of all it shouldn't remove sqlite in any case (DNF requires sqlite and DNF is protected package) -> added missing requirement to DNF spec. (In reply to Fabio Valentini from comment #0) > Created attachment 1027037 [details] > corpus delicti > > I did the following: > - dnf install alacarte > - dnf remove alacarte > > What happened: > dnf removed alacarte. > AND dnf autoremoved zlib(!) and sqlite > > - which results in an utterly unusable and broken system. > I could only repair it from another install of fedora on a seperate > partition. > > Might this problem be a leftover of the rpm package dependency generation > bug I read about? I don't know what you are talking about. Can you post #BZ? > If this also happens in the background when removing software in > gnome-software Gnome-software don't use DNF - it uses DNF's C libraries and probably doesn't do autoremove. Was there a time where you didn't have sqlite package installed and you had to install it manually? When such removal triggers again, can you stop the transaction and post output of `dnf history userinstalled`, `dnf list installed` and attach debugdata [1] after execution of `dnf autoremove --debugsolver --assumeno`, please? [1] https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#dependency-resolution-problem
I will try to gather more information about the issue if it pops up again. In the meantime, I found the bug report I mentioned: https://bugzilla.redhat.com/show_bug.cgi?id=1207945 One of the commenters (comm #3) points out that the bug might result in many packages shipping for f22 without correct dependencies (I don't think all affected packages have been rebuilt in the meantime).
(In reply to Jan Silhan from comment #1) > First of all it shouldn't remove sqlite in any case > (DNF requires sqlite and DNF is protected package) -> added missing > requirement to DNF spec. No, it requires Python's sqlite which is part of Python's standard library.
I just had the same happen: Here it is trying to remove sqlite: dnf remove sqlite.i686 Dependencies resolved. ========================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================== Removing: nss i686 3.19.1-1.0.fc22 @System 2.4 M nss-softokn i686 3.19.1-1.0.fc22 @System 1.1 M sqlite i686 3.8.10.2-1.fc22 @System 939 k sqlite x86_64 3.8.10.2-1.fc22 @System 922 k Transaction Summary ========================================================================================================================================== Remove 4 Packages Installed size: 5.3 M Is this ok [y/N]: n Operation aborted. Here it removed zlib on me. I had to copy libz.so.1 back on a thumb drive so I could reinstall it... dnf remove ntfsprogs Dependencies resolved. ========================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================== Removing: ntfs-3g x86_64 2:2015.3.14-2.fc22 @System 661 k ntfsprogs x86_64 2:2015.3.14-2.fc22 @System 872 k zlib x86_64 1.2.8-7.fc22 @System 184 k Transaction Summary ========================================================================================================================================== Remove 3 Packages Installed size: 1.7 M Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Erasing : ntfsprogs-2:2015.3.14-2.fc22.x86_64 1/3 Erasing : ntfs-3g-2:2015.3.14-2.fc22.x86_64 2/3 Erasing : zlib-1.2.8-7.fc22.x86_64 3/3 Verifying : zlib-1.2.8-7.fc22.x86_64 1/3 Verifying : ntfs-3g-2:2015.3.14-2.fc22.x86_64 2/3 Verifying : ntfsprogs-2:2015.3.14-2.fc22.x86_64 3/3 Removed: ntfs-3g.x86_64 2:2015.3.14-2.fc22 ntfsprogs.x86_64 2:2015.3.14-2.fc22 zlib.x86_64 1.2.8-7.fc22 Complete! [root@mini ~]# clear [3;J [root@mini ~]# dnf leaves Traceback (most recent call last): File "/usr/bin/dnf", line 35, in <module> from dnf.cli import main File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python2.7/site-packages/dnf/base.py", line 26, in <module> from dnf.comps import CompsQuery File "/usr/lib/python2.7/site-packages/dnf/comps.py", line 29, in <module> import dnf.util File "/usr/lib/python2.7/site-packages/dnf/util.py", line 31, in <module> import librepo File "/usr/lib64/python2.7/site-packages/librepo/__init__.py", line 1001, in <module> import librepo._librepo ImportError: libz.so.1: cannot open shared object file: No such file or directory [root@mini ~]# dnf leaves Traceback (most recent call last): File "/usr/bin/dnf", line 35, in <module> from dnf.cli import main File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python2.7/site-packages/dnf/base.py", line 26, in <module> from dnf.comps import CompsQuery File "/usr/lib/python2.7/site-packages/dnf/comps.py", line 29, in <module> import dnf.util File "/usr/lib/python2.7/site-packages/dnf/util.py", line 31, in <module> import librepo File "/usr/lib64/python2.7/site-packages/librepo/__init__.py", line 1001, in <module> import librepo._librepo ImportError: libz.so.1: cannot open shared object file: No such file or directory
Created attachment 1041245 [details] dnf trying to remove sqlite plus output requested.
and it will allow removal of libidn: dnf leaves Traceback (most recent call last): File "/usr/bin/dnf", line 35, in <module> from dnf.cli import main File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python2.7/site-packages/dnf/base.py", line 26, in <module> from dnf.comps import CompsQuery File "/usr/lib/python2.7/site-packages/dnf/comps.py", line 29, in <module> import dnf.util File "/usr/lib/python2.7/site-packages/dnf/util.py", line 31, in <module> import librepo File "/usr/lib64/python2.7/site-packages/librepo/__init__.py", line 1001, in <module> import librepo._librepo ImportError: libidn.so.11: cannot open shared object file: No such file or directory
Created attachment 1041423 [details] debug data
Same for me with transmission root@linux-2-1 [05:44:32] [/var/lib/transmission] -> # dnf remove transmission Dépendances résolues. =================================================================================================================================================================== Paquet Architecture Version Dépôt Taille =================================================================================================================================================================== Suppression : libidn x86_64 1.29-3.fc22 @System 586 k transmission-common x86_64 2.84-7.fc22 @System 2.9 M transmission-daemon x86_64 2.84-7.fc22 @System 549 k Résumé de la transaction =================================================================================================================================================================== Supprimer 3 Packages Taille d'installation : 4.0 M Est-ce correct [o/N] : o Test de la transaction en cours La vérification de la transaction a réussi. Lancement de la transaction de test Transaction de test réussie. Exécution de la transaction Suppression : transmission-daemon-2.84-7.fc22.x86_64 1/3 Suppression : transmission-common-2.84-7.fc22.x86_64 2/3 Suppression : libidn-1.29-3.fc22.x86_64 3/3 Vérifie : libidn-1.29-3.fc22.x86_64 1/3 Vérifie : transmission-common-2.84-7.fc22.x86_64 2/3 Vérifie : transmission-daemon-2.84-7.fc22.x86_64 3/3 Supprimés : libidn.x86_64 1.29-3.fc22 transmission-common.x86_64 2.84-7.fc22 transmission-daemon.x86_64 2.84-7.fc22
Fabio, can you post the output of "sudo dnf history userinstalled", please?
Created attachment 1055271 [details] output of dnf history userinstalled I think sqlite and zlib show up in this list because I had to copy libz.so.0 and libsqlite3.so.0 over from my fedora rawhide partition and reinstall the packages manually.
I just had the same issue trying to uninstall gstreamer1-libav, which automatically removed libidn and primus, resulting in a broken system because of dnf no longer finding libidn: ➜ Videos sudo dnf remove gstreamer1-libav Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: gstreamer1-libav x86_64 1.4.5-1.fc22 @System 7.3 M libidn x86_64 1.32-1.fc22 @System 647 k primus x86_64 1.1.03282015-2.fc22 @System 339 k Transaction Summary ================================================================================ Remove 3 Packages Installed size: 8.3 M Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Erasing : primus-1.1.03282015-2.fc22.x86_64 1/3 Erasing : libidn-1.32-1.fc22.x86_64 2/3 Erasing : gstreamer1-libav-1.4.5-1.fc22.x86_64 3/3 Verifying : gstreamer1-libav-1.4.5-1.fc22.x86_64 1/3 Verifying : libidn-1.32-1.fc22.x86_64 2/3 Verifying : primus-1.1.03282015-2.fc22.x86_64 3/3 Removed: gstreamer1-libav.x86_64 1.4.5-1.fc22 libidn.x86_64 1.32-1.fc22 primus.x86_64 1.1.03282015-2.fc22 Complete! ➜ Videos sudo dnf install primus Traceback (most recent call last): File "/bin/dnf", line 35, in <module> from dnf.cli import main File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python2.7/site-packages/dnf/base.py", line 26, in <module> from dnf.comps import CompsQuery File "/usr/lib/python2.7/site-packages/dnf/comps.py", line 29, in <module> import dnf.util File "/usr/lib/python2.7/site-packages/dnf/util.py", line 31, in <module> import librepo File "/usr/lib64/python2.7/site-packages/librepo/__init__.py", line 1001, in <module> import librepo._librepo ImportError: libidn.so.11: cannot open shared object file: No such file or directory
I too had an issue where "dnf remove cockpit" would remove selinux-policy and selinux-policy-targeted, resulting in SELinux getting disabled without warning. This only happens on systems where I used gnome-software to update packages, instead of relying solely on dnf.
If it helps in anyway, I too use gnome-software to upgrade my system from time to time (in fact, I just had my system upgraded with the offline upgrade available in Gnome).
*** Bug 1260299 has been marked as a duplicate of this bug. ***
See bug 1259865, but it appears this behavior can be caused by installing things with wonky "Provides:", using PackageKit. In my case, the "plexmediaserver" RPM claims to Provide the same things as libidn, so erasing packages could cause libidn to be auto-removed. Reinstalling "plexmediaserver" using DNF was sufficient to fix problem.
(In reply to Will Woods from comment #17) > Reinstalling "plexmediaserver" using DNF was sufficient to fix problem. Please, let me note that it's just a coincidence that "dnf reinstall" "fixes" the problem. There is a bug in how DNF handles the "userinstalled" flag when reinstalling packages. It completely removes the information about the reason why a package was installed which in turn results in handling the package as "userinstalled". And TBH I'm not sure how would the reinstall command behave (in this respect) once we fix it. I'd rather recommend people the new "dnf mark install" command once DNF 1.1.1 is pushed to stable.
Hello, I'm experiencing exactly the same issue and I'm also using plexmediaserver. Please, how can I reinstall this app with dnf if any action with dnf returns the same error? Graphic apps for apps management doesn't work as well. Thanks
(In reply to Tomas Drvota from comment #19) > I'm experiencing exactly the same issue and I'm also using plexmediaserver. > Please, how can I reinstall this app with dnf if any action with dnf returns > the same error? Graphic apps for apps management doesn't work as well. To fix DNF, you can download the libidn package manually (from a mirror or http://koji.fedoraproject.org/) and install it using `rpm -ivh`.
I have had this problem many times now (last time with libidn when removing transmission-deamon). Steps to fix in addition to Will's tip before if your RPM is not working: Download package to your computer from http://koji.fedoraproject.org/koji/ . If you can't use RPM because it's broken, use a Mac or another Linux and run for example: `rpm2cpio libidn-1.32-1.fc22.x86_64.rpm | cpio -idmv` and copy over the source (you'll have to symlink them by hand). Other option: run identical virtualbox on another computer and copy the files over.
I just tried out all the triggers mentioned above, and none of them caused the unwanted behaviour anymore. And I did not encounter this problem in a while now, has it been fixed? And if so, would someone please confirm that, so this bug can be closed? Just trying to clean up after myself on RHBZ ...
I can confirm that the issue with libidn removal was caused by plexmediaserver package, which does not seem to be shipped by Fedora. I also presume that the zlib removal was based on the similar principle. If there is anybody who can reproduce removing of zlib, please reopen this report and provide a debugdata (--debugsolver).
*** Bug 1280451 has been marked as a duplicate of this bug. ***
Same problem here with intltool and liferea packages: $ sudo dnf remove intltool Dependencies resolved. ========================================================================================================= Package Arch Version Repository Size ========================================================================================================= Removing: autoconf noarch 2.69-21.fc23 @fedora 2.2 M automake noarch 1.15-4.fc23 @fedora 1.7 M gettext-common-devel noarch 0.19.6-1.fc23 @fedora 380 k gettext-devel x86_64 0.19.6-1.fc23 @fedora 1.4 M intltool noarch 0.51.0-3.fc23 @fedora 169 k m4 x86_64 1.4.17-8.fc23 @fedora 526 k patch x86_64 2.7.5-2.fc23 @fedora 231 k perl-Thread-Queue noarch 3.07-1.fc23 @updates 28 k perl-XML-Parser x86_64 2.44-3.fc23 @fedora 627 k zlib x86_64 1.2.8-9.fc23 @fedora 183 k Transaction Summary ========================================================================================================= Remove 10 Packages $ sudo dnf remove liferea Dependencies resolved. ========================================================================================================= Package Arch Version Repository Size ========================================================================================================= Removing: libogg x86_64 2:1.3.2-4.fc23 @koji-override-0 34 k libpng x86_64 2:1.6.19-1.fc23 @updates 211 k libuuid x86_64 2.27.1-2.fc23 @updates 21 k liferea x86_64 1:1.10.17-1.fc23 @updates 3.0 M sqlite x86_64 3.9.0-1.fc23 @updates 942 k zlib x86_64 1.2.8-9.fc23 @fedora 183 k Transaction Summary ========================================================================================================= Remove 6 Packages Also autoremove won't work: $ sudo dnf autoremove --debugsolver --assumeno Last metadata expiration check performed 0:14:09 ago on Thu Dec 10 09:08:17 2015. Error: problem with installed package libogg-2:1.3.2-4.fc23.i686. problem with installed package libpng12-1.2.50-9.fc23.i686. problem with installed package libtxc_dxtn-1:1.0.1-1.gitef072983.fc23.i686. problem with installed package zlib-1.2.8-9.fc23.i686 (try to add '--allowerasing' to command line to replace conflicting packages)
I think this is really serious and should be investigated further (no plexmediaserver installed on my box): $ sudo dnf remove gnome-mines-3.18.2-1.fc23.x86_64 [sudo] password for kristi: Dependencies resolved. ============================================================================================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================================================================================== Removing: gnome-mines x86_64 3.18.2-1.fc23 @updates 6.5 M libpng x86_64 2:1.6.19-1.fc23 @updates 211 k sqlite x86_64 3.9.0-1.fc23 @updates 942 k zlib x86_64 1.2.8-9.fc23 @koji-override-0 183 k Transaction Summary ============================================================================================================================================================================================================================================== Remove 4 Packages Installed size: 7.8 M Is this ok [y/N]: n Operation aborted. Could it be because zlib is provided both by the 64bit and the 32bit package, and the requirements of the packages needing zlib.x86_64 do not specify the architecture? [kristi@papoi ~]$ rpm -q --whatprovides zlib zlib-1.2.8-9.fc23.x86_64 zlib-1.2.8-9.fc23.i686
A workaround was to re-install zlib; this seems to fix the problem for the moment, but still!
*** Bug 1293964 has been marked as a duplicate of this bug. ***
*** Bug 1296289 has been marked as a duplicate of this bug. ***
*** Bug 1319967 has been marked as a duplicate of this bug. ***
*** Bug 1325736 has been marked as a duplicate of this bug. ***