I destroyed my dnf installation

This happen like a month ago, i wanst even aware that dnf wasnt here anymore. Yeah. I was mad because of that thrash package “manager” called pip installed tensorflow globally (??) even today i don’t know why.

So after I set up a virtual env, pip rejected the tensorflow uninstall command, i tried many approaches to get that f*up pip to erase tensorflow global install, no luck, so I manually erased site-packages folder.

I would never imagined that a critical system dependency would reside in a, CLEARLY (at least to me =) ), volatile module folder for cached dependency storage.

I tried to install dnf from pip (since it was inside python, and pip is the package manager of python…), but yeah… to no avail.

Any ideas (other than swap to ubuntu).

Thank you!!!

So have you tried to type dnf check for instance in the command line? Dnf is the Fedora package manager, while pip is only for python packages. Dnf is not a python package. I don’t think you’ll ever find it inside a Python virtual environment.

thank you.
This is the cmdline response:

Traceback (most recent call last):
File “/usr/bin/dnf”, line 61, in
from dnf.cli import main
ModuleNotFoundError: No module named ‘dnf’

Im almost positive that there were important deps in site-packages. But ty!

Just to clarify, what i erased was the global site-packages folder, not the virtual env. I set up a virtual env after i installed tflow globally. Thats why i wanted to erase it, since it was no longer necessary.

I’m pretty sure you can use Feodra’s installer to repair a system.

You can download dnf from koji (dnf | Package Info | koji) and use rpm to install it.
You will have to do the same with dependencies of dnf, which I don’t know by heart.

sudo rpm -ivh dnf…

or from the directory to which you downloaded the dnf and its dependencies‘ rpms:

sudo rpm -ivh *.rpm

Edit: you need at least python3-dnf in addition.

thank you.

I tried to do this:
wget -qO- https://kojipkgs.fedoraproject.org/packages/dnf/4.14.0/1.fc35/noarch/dnf-4.14.0-1.fc35.noarch.rpm | sudo rpm -i --nodeps -
[sudo] password for asdf:
package dnf-4.14.0-1.fc35.noarch is already installed
package dnf-4.14.0-1.fc35.noarch does not verify: (null)

i dont know what that null is. But since it doesnt want to install it doesnt make any sense to care about other deps that dnf may have.

well i manage to reinstall dnf.

The error continues:

Traceback (most recent call last):
File “/usr/bin/dnf”, line 61, in
from dnf.cli import main
ModuleNotFoundError: No module named ‘dnf’

I suppose i could try a system recovery from the grub.

Try installing the python3-dnf package.

Verifying… ################################# [100%]
Preparing… ################################# [100%]
package python3-dnf-4.14.0-1.fc35.noarch is already installed
[julian@fedora Downloads]$ dnf
Traceback (most recent call last):
File “/usr/bin/dnf”, line 61, in
from dnf.cli import main
ModuleNotFoundError: No module named ‘dnf’

No luck, but thank you.

I think could be this one?


It has more depencencies… yeah… this is useless…

Did you pass the --replacepkgs option to rpm so rpm would reinstall it? From the output it looks like rpm did not actually install the new rpm, because it was already installed.

1 Like

I just tested it out in a container and this should work:

rpm --verbose --replacepkgs -i https://kojipkgs.fedoraproject.org//packages/dnf/4.14.0/1.fc35/noarch/python3-dnf-4.14.0-1.fc35.noarch.rpm

If you removed /usr/lib/python3.11/site-packages/, it would damage all Python 3 packages[1], not just dnf and its dependencies.

These are all the Python 3 packages in the dnf dependency chain[2]:


excluding python3 package itself, which doesn’t contain any files in site-packages.

2 possible solutions:

  1. Install all these packages manually from Koji. You can use packages.fedoraproject.org to search. Once dnf is fixed you’ll still need to reinstall all other installed python3-* packages.

  2. Boot a live install USB, mount your hard disk, and use dnf --installroot=</path/to/hdd> to reinstall all installed python3-* packages (see --installroot docs). I’m not 100% sure on this method; it would be much smoother of course if it works, but please get a 2nd opinion.

Secret 3rd solution is to restore from the regular backups you made…

  1. For reference, I have over 200 python3-* packages installed, which is not unusual. ↩︎

  2. I hope it’s correct. Roughly obtained using: dnf -qC rq --requires dnf --tree | grep -Eo 'python3-[^, ]+' | sort -u ↩︎


Even with a venv the global site-packages are necessary. There are many python modules that reside there and are used by the venv packages. In fact, I use a venv for several tools but most of the dependencies are installed globally. I am not sure that python will even function without the default installed global packages.

1 Like

If you are on Fedora 38 you may be able to install dnf5 and use it to re-install all the python packages. The packages to download are dnf5, libdnf5 and libdnf5-cli.


rpm database is sqlite now. Unfortunately this might not help the O.P. unless the transition to sqlite was already done in FC35

Is there a rpm command displaying all packages which have files in a given path?

With Sqlite this could be done quite easily:

if test $# -ne 1 -o  "${1:0:1}" != "/"
	echo One absolute path expected
cat <<end | sqlite3 /var/lib/rpm/rpmdb.sqlite
select distinct Name.key from Name  
inner join dirnames on dirnames.hnum=Name.hnum
where dirnames.key like '${1}%'; 


./rpmq /usr/lib/python3.11/site-packages | head
[hj@lap2 ~]$ ./rpmq /usr/lib/python3.11/site-packages | wc
    323     323    5738

So: 323 packages would be affected by removing site-packages

Include subdirectory dnf:

./rpmq /usr/lib/python3.11/site-packages/dnf

So these packages should be downloaded and installed manuallly

Now restoring the system is simple:

sudo dnf reinstall $(./rpmq /usr/lib/python3.11/site-packages)

A few packages are rejected because you cannot reinstall a package from which an update exists, but they will be repaired next step by “dnf update”

1 Like


Thank you so so so so so much. You are MY favorite person!!

Yeah that got it. Its working!!!

If any dev of the fedora project read this. I TOTALLY advice you to issue a migration of this library to c++. Im assure you this will happen again and again.

That’s not how linux works. When someone identifies a problem, they have to work on a solution. Fedora already has C++ based dnf5. Have you installed and tested this version?

There is also librpm.rs (rust-based tool). If the python implementation proves problematic as you predict, and C++ looks like the best way forward, then others will help improve the project and everyone will benefit.

There are many other efforts to provide better RPM software managers: Collected RPM software manager efforts on github.

1 Like