How to recover a broken Dnf? after installing keras

Well I thought that stuff like pip were not supposed to be designed to break your system

No, pip makes no such claims. It is simply a tool to install packages from PyPi. How and where these are installed is left up to the user.

This is the usecase that anaconda and python virtual environments aim to address. Every user, with or without sudo access can create a new virtual environment in their home folders and install whatever packages they wish without interacting with the system-wide python installation at all. They can have multiple virtual environments too—so you can have one for keras, another for another tool—all independent of each other. When using root in general, you should be more careful to see what’s being done.

Does dnf work at all? What is the output of:

rpm -qa \*dnf\* \*repo\*

?

Let’s see if we can reinstall it etc to fix it.

Mh ok so it messed up the environment that dnf’s python files are using I guess.

I got the usage of RPM:

RPM version 4.14.2.1
Copyright (C) 1998-2002 - Red Hat, Inc.
This program may be freely redistributed under the terms of the GNU GPL

after that there is the list of flags available
However it produces the exit code 4

I suspect deactivating your current environment should hopefully fix your issue (if the sytem files were not messed up by installing conda initially):

Well, that did not work unfortunately…:
conda deactivate
dnf
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 31, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 26, in <module>
from dnf.comps import CompsQuery
File "/usr/lib/python3.6/site-packages/dnf/comps.py", line 29, in <module>
import dnf.util File "/usr/lib/python3.6/site-packages/dnf/util.py", line 32, in <module>
import librepo
File "/usr/lib64/python3.6/site-packages/librepo/__init__.py", line 1077, in <module>
import librepo._librepo
ImportError: /lib64/libcurl.so.4: symbol SSLv3_client_method version OPENSSL_1_1_0 not defined in file libssl.so.1.1 with link time reference

I guess removing conda would do the trick, but then I would not know how to reinstall it properly

Yes, possibly the system-wide python installation that dnf and other tools rely on. But we’ll see :slight_smile:

Are you sure you ran the command correctly? (Copy pasting should work). I get the expected results here.

No, it won’t unfortunately—removing conda will not bring back the files that were overwritten—but we don’t know if that’s the issue yet.

Can you try this modified command again please?

rpm -qa \*dnf\* \*repo\* \*ssl\*

The output of uname -a would also be useful.

I looked at this page. One or two things of note:

  • it does not seem to require the use of sudo at all, so you shouldn’t use it if you install keras again.
  • it installs a version of openssl different from the fedora version. So, if you used sudo and it overwrote the system version, that could be the cause of the error you are seeing.

The output of

rpm -qa \*dnf\* \*repo\* \*ssl\*

will tell us more.

At first I did not use sudo, but the first step failed because it needed to write in a write-protected directory, so I had to use sudo (which I kept using).

Sorry… used -sa instead of -qa, here is the result:

dnf-2.7.5-12.fc28.noarch
libreport-plugin-systemd-journal-2.9.5-3.fc28.x86_64
libreport-filesystem-2.9.5-3.fc28.x86_64
createrepo_c-libs-0.10.0-19.fc28.x86_64
python3-dnf-plugins-core-2.1.5-4.fc28.noarch
python3-dnf-plugins-extras-common-2.0.5-3.fc28.noarch
python3-libreport-2.9.5-3.fc28.x86_64
python3-librepo-1.8.1-7.fc28.x86_64
libreport-plugin-kerneloops-2.9.5-3.fc28.x86_64
python3-dnf-plugin-system-upgrade-2.0.5-3.fc28.noarch
libreport-web-2.9.5-3.fc28.x86_64
libdnf-0.11.1-6.fc28.1.x86_64
libreport-plugin-bugzilla-2.9.5-3.fc28.x86_64
fedora-repos-28-7.noarch
dnf-plugins-core-2.1.5-4.fc28.noarch
libreport-plugin-ureport-2.9.5-3.fc28.x86_64
python3-dnf-2.7.5-12.fc28.noarch
dnf-yum-2.7.5-12.fc28.noarch
libreport-plugin-logger-2.9.5-3.fc28.x86_64
libreport-2.9.5-3.fc28.x86_64
dnfdaemon-selinux-0.3.18-6.fc28.noarch
libreport-gtk-2.9.5-3.fc28.x86_64
dnf-conf-2.7.5-12.fc28.noarch
createrepo_c-0.10.0-19.fc28.x86_64
dnfdaemon-0.3.18-6.fc28.noarch
libreport-anaconda-2.9.5-3.fc28.x86_64
python2-repoze-lru-0.4-17.fc28.noarch
libreport-cli-2.9.5-3.fc28.x86_64
librepo-1.8.1-7.fc28.x86_64
libreport-plugin-reportuploader-2.9.5-3.fc28.x86_64
dnfdragora-1.1.1-1.fc28.noarch
claws-mail-plugins-spam-report-3.16.0-1.fc28.x86_64
python3-dnfdaemon-0.3.18-6.fc28.noarch
libreport-fedora-2.9.5-3.fc28.x86_64

And the one for rpm -qa \*dnf\* \*repo\* \*ssl\*:

dnf-2.7.5-12.fc28.noarch
libreport-plugin-systemd-journal-2.9.5-3.fc28.x86_64
libreport-filesystem-2.9.5-3.fc28.x86_64
createrepo_c-libs-0.10.0-19.fc28.x86_64
python3-dnf-plugins-core-2.1.5-4.fc28.noarch
openssl-1.1.0i-1.fc28.x86_64
mingw64-openssl-1.0.2h-6.fc28.noarch
python3-dnf-plugins-extras-common-2.0.5-3.fc28.noarch
python3-libreport-2.9.5-3.fc28.x86_64
python3-librepo-1.8.1-7.fc28.x86_64
libreport-plugin-kerneloops-2.9.5-3.fc28.x86_64
openssl-libs-1.1.0i-1.fc28.x86_64
python3-dnf-plugin-system-upgrade-2.0.5-3.fc28.noarch
libreport-web-2.9.5-3.fc28.x86_64
docbook-style-dsssl-1.79-25.fc28.noarch
libdnf-0.11.1-6.fc28.1.x86_64
libreport-plugin-bugzilla-2.9.5-3.fc28.x86_64
compat-openssl10-pkcs11-helper-1.22-4.fc28.x86_64
fedora-repos-28-7.noarch
dnf-plugins-core-2.1.5-4.fc28.noarch
libreport-plugin-ureport-2.9.5-3.fc28.x86_64
python3-dnf-2.7.5-12.fc28.noarch
dnf-yum-2.7.5-12.fc28.noarch
apr-util-openssl-1.6.1-8.fc28.x86_64
libreport-plugin-logger-2.9.5-3.fc28.x86_64
NetworkManager-fortisslvpn-gnome-1.2.8-2.fc28.x86_64
libreport-2.9.5-3.fc28.x86_64
dnfdaemon-selinux-0.3.18-6.fc28.noarch
libreport-gtk-2.9.5-3.fc28.x86_64
mingw32-openssl-1.0.2h-6.fc28.noarch
dnf-conf-2.7.5-12.fc28.noarch
xmlsec1-openssl-1.2.25-4.fc28.x86_64
createrepo_c-0.10.0-19.fc28.x86_64
dnfdaemon-0.3.18-6.fc28.noarch
compat-openssl10-1.0.2o-1.fc28.x86_64
libreport-anaconda-2.9.5-3.fc28.x86_64
openssl-pkcs11-0.4.8-2.fc28.x86_64
python2-repoze-lru-0.4-17.fc28.noarch
libreport-cli-2.9.5-3.fc28.x86_64
librepo-1.8.1-7.fc28.x86_64
libreport-plugin-reportuploader-2.9.5-3.fc28.x86_64
dnfdragora-1.1.1-1.fc28.noarch
openssl-devel-1.1.0i-1.fc28.x86_64
claws-mail-plugins-spam-report-3.16.0-1.fc28.x86_64
python3-dnfdaemon-0.3.18-6.fc28.noarch
NetworkManager-fortisslvpn-1.2.8-2.fc28.x86_64
rubygem-openssl-2.1.2-95.fc28.x86_64
libreport-fedora-2.9.5-3.fc28.x86_64
python2-backports-ssl_match_hostname-3.5.0.1-8.fc28.noarch

And uname -a:

Linux linux.home 5.0.7-100.fc28.x86_64 #1 SMP Mon Apr 8 16:46:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I am thinking about reinstalling the whole OS… But before that I might try reinstalling dnf or python, might fix it. Do you have any other solution @FranciscoD ?

Can you please do the following?:

download dnf from koji : dnf 2.7.5-12

and then:

sudo rpm -ivh *.rpm

NOTE: Please don’t use this as your day to day tool

REMEMBER : Fedora 28 will be EOL on Tuesday, May 28th, 2019 - #2

Regards.,

1 Like

Done, but the installation had a warning:

sudo rpm -ivh dnf-2.7.5-12.fc28.src.rpm 
Updating / installing...
dnf-2.7.5-12.fc28                warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
################################# [100%]

I still have the same issue as before…

Why not? Isn’t that dnf?

Well I am usually using dnf to update to the newer version of fedora, so…

You download the source, you have to download this packages:

then execute, this command to reinstall dnf, you need all of this for dependency problem:

sudo rpm -ivh *.rpm

After this, try to use dnf

Regards.,

NOTE: however is only a warning.

1 Like

There is also a tool: koji (sudo dnf install koji).
Then you can download the various RPMs associated with a build (the number you can see in the web page).

cd ~/Downloads && koji download-build -a noarch 1073265

1 Like

@alciregi good to know but his/her dnf is broken

1 Like

whoops, right right :sweat:

2 Likes

Ok so I had to install the dependencies of these dependencies as well:

dnf_dependencies ls
dnf-2.7.5-12.fc28.noarch.rpm            dnf-yum-2.7.5-12.fc28.noarch.rpm  pyliblzma-0.5.3-21.fc28.x86_64.rpm    python2-hawkey-0.11.1-3.fc28.x86_64.rpm    python2-librepo-1.8.1-7.fc28.x86_64.rpm
dnf-automatic-2.7.5-12.fc28.noarch.rpm  libdnf-0.11.1-3.fc28.x86_64.rpm   python2-dnf-2.7.5-12.fc28.noarch.rpm  python2-iniparse-0.4-30.fc28.noarch.rpm    python2-smartcols-0.3.0-2.fc28.x86_64.rpm
dnf-conf-2.7.5-12.fc28.noarch.rpm       libsolv-0.6.34-1.fc28.x86_64.rpm  python2-gpg-1.10.0-4.fc28.x86_64.rpm  python2-libcomps-0.1.8-11.fc28.x86_64.rpm  python3-dnf-2.7.5-12.fc28.noarch.rpm

but ended up with another error (dnf still not working):

sudo rpm -ivh *.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
package libsolv-0.7.2-1.fc28.x86_64 (which is newer than libsolv-0.6.34-1.fc28.x86_64) is already installed
file /usr/share/doc/libsolv/README from install of libsolv-0.6.34-1.fc28.x86_64 conflicts with file from package libsolv-0.7.2-1.fc28.x86_64
package dnf-conf-2.7.5-12.fc28.noarch is already installed
package python3-dnf-2.7.5-12.fc28.noarch is already installed
package dnf-2.7.5-12.fc28.noarch is already installed
package libdnf-0.11.1-6.fc28.1.x86_64 (which is newer than libdnf-0.11.1-3.fc28.x86_64) is already installed
file /usr/lib64/libdnf.so.1 from install of libdnf-0.11.1-3.fc28.x86_64 conflicts with file from package libdnf-0.11.1-6.fc28.1.x86_64
package dnf-yum-2.7.5-12.fc28.noarch is already installed

Shall I uninstall these packages and reinstall them?

No, you’re using rpm now. As you’ve seen below,rpm does not track deps. dnf does, and then uses the rpm library to carry out whole transactions with lots of packages.

I was leaning towards a fresh install because it isn’t yet clear to me that the error is in dnf. The error speaks about libcrypt so it could be in the openssl package too. In short, pip touched lots of files, and all packages that any of these files belong to may need to be reinstalled. It’s doable, but it generally requires lots of step by step work.

If you do want to give that a go, I’d start by checking the obvious packages: dnf and packages it depends on. You could check to see what pip did, and get some idea of what files it overwrote.

rpm --verify ...

will tell you that.

I did not understand he was talking about rpm, thought it was the dnf package to download using koji, my bad.

Sure, I’m willing to reinstall properly everything

Uh, so I need to do rpm --verify on every single package that dnf depends on? what result am I expecting?

Yeh, sort of. Although, you can just run rpm --verify -a to verify your whole system. This will give you some results that are documented in man rpm. I paste them here for your convenience:

       The format of the output is a string of 9 characters, a possible attribute marker:

       c %config configuration file.
       d %doc documentation file.
       g %ghost file (i.e. the file contents are not included in the package payload).
       l %license license file.
       r %readme readme file.

       from the package header, followed by the file name.  Each of the 9 characters denotes the result of a comparison of attribute(s) of the file to the value  of  those  attribute(s)
       recorded	 in  the database.  A single "." (period) means the test passed, while a single "?" (question mark) indicates the test could not be performed (e.g. file permissions pre‐
       vent reading). Otherwise, the (mnemonically emBoldened) character denotes failure of the corresponding --verify test:

       S file Size differs
       M Mode differs (includes permissions and file type)
       5 digest (formerly MD5 sum) differs
       D Device major/minor number mismatch
       L readLink(2) path mismatch
       U User ownership differs
       G Group ownership differs
       T mTime differs
       P caPabilities differ

You will then go through the results and see which files have changed, and then manually reinstall them using rpm as @hhlp directed you to.

So, yeh, can be done, but not sure it’s worth the effort.

I bricked my system all the time, I still do. My solution is generally to fresh install (which generally seems quicker to me especially if using a Live image), and to make it easier I:

  • ensure I have a separate /home partition that I just mount on every fresh install
  • ensure I have regular backups
  • have a script that quickly installs all my packages (mine is here)

So usually, if I brick something, I let it reinstall at night, and by morning I’m back to a functional system a little wiser than the previous day :slight_smile:

Nice. I’ll be trying to modify this script to suit my needs. :smile:

1 Like

So, since it was kind of long to go through each package and fix them, and that I did not any major unrecoverable things in my computer, I actually reinstalled fedora (30) from scratch so it’s all fine now!
Thank you everyone!

1 Like