How to recover a broken Dnf? after installing keras

Ask Fedora Ask in English
21

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?

22

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.

23

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?

24

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:

25

Nice. Iā€™ll be trying to modify this script to suit my needs. :smile:

1 Like
26

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