Dnf is completely broken: ImportError: /lib64/libzck.so.1: cannot read file data: Is a directory

,

dnf is completely broken, no command works (install, update, help)
Here is the terminal output

Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.10/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.10/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python3.10/site-packages/libdnf/__init__.py", line 12, in <module>
    from . import conf
  File "/usr/lib64/python3.10/site-packages/libdnf/conf.py", line 13, in <module>
    from . import _conf
ImportError: /lib64/libzck.so.1: cannot read file data: Is a directory

Also I have noticed that the preview functionality of nautilus is not working, might be related.

Hi @giannissc , welcome to the community. Please take a minute to go through the introductory posts in the #start-here category if you’ve not had the chance to do so yet.

Can you provide us with more information please—only the terminal output is not enough here because we don’t know what’s changed the shared object it is trying to open.

  • what version of Fedora Linux is this (assuming it’s Fedora 35, but good to confirm)?
  • when did this start?
  • have you installed any new software, and how (from source?)

Can you also give us the output of this command please (it should not be a directory, it should be a symlink to another file)

ls -lash /lib64/libzck*
1 Like

That is indeed very odd as libzck.so should definitely not be a directory. Are you able to provide some more context for what happened leading up to this?

EDIT: (My apologes to @ankursinha as my reply appears to be redundant.)

1 Like

To be honest with you both I am not really sure when this happened. I have just noticed that software centre being unable to show any update which happened in the past and it got back to normal after a restart so I didn’t give much attention to it. All the software I use either comes from flathub or snapcraft. The last few commands that I run were related to flatpak updates, I tried install gnome tracker but that was already installed and deleting nvidia drivers

As per request:

uname -r

5.16.13-200.fc35.x86_64

uname -r

5.16.13-200.fc35.x86_64

cat /etc/os-release

ID=fedora
VERSION_ID=35
VERSION_CODENAME=""
PLATFORM_ID="platform:f35"
PRETTY_NAME="Fedora Linux 35 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:35"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f35/system-administrators-guide/"
SUPPORT_URL="https://discussion.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=35
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=35
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation

ls -lash /lib64/libzck*

   0 lrwxrwxrwx. 1 root root   0 Mar 12 17:01 /lib64/libzck.so.1 -> ''
100K -rwxr-xr-x. 1 root root 98K Feb 20 17:34 /lib64/libzck.so.1.2.0
   0 -rwxr-xr-x. 1 root root   0 Mar 12 17:01 /lib64/libzck.so.1.2.1

That looks really strange, as if you did not copy everything or it is not actually correct. On my fedora 35 system I see

$ ls -lash /lib64/libzck*
   0 lrwxrwxrwx. 1 root root  15 Mar 12 11:01 /lib64/libzck.so.1 -> libzck.so.1.2.1
100K -rwxr-xr-x. 1 root root 98K Mar 12 11:01 /lib64/libzck.so.1.2.1

and

$ ls -lash /usr/lib64/libzck*
   0 lrwxrwxrwx. 1 root root  15 Mar 12 11:01 /usr/lib64/libzck.so.1 -> libzck.so.1.2.1
100K -rwxr-xr-x. 1 root root 98K Mar 12 11:01 /usr/lib64/libzck.so.1.2.1

and

$ ls -ld /lib64
lrwxrwxrwx. 1 root root 9 Jul 21  2021 /lib64 -> usr/lib64

Thus it would appear somehow you have gotten the link for /usr/lib64/libzck.so.1 to be invalid and also somehow have an additional /lib64/libzck.so.1.2.0 that does not exist for me. I would guess that somewhere in the update the new library file did not get fully put into place and the link was not properly updated to point to the new file.

You may be able to do a repair by reinstalling the package that provides that file with rpm
sudo rpm --reinstall zchunk-libs
It might be necessary to first remove the improperly identified file(s) sudo rm /lib64/libzck.so.1*

2 Likes

It turns out that two libraries of zchunk were installed at the time time. I deleted one but the other seems to be problematic and needs to be reinstalled. I have tried downloading the rpm package for zchunk but I can’t install it. I get this error message even though I have all dependencies installed pkgconfig(libzstd) is needed by zchunk-devel-1.2.1-1.fc35.x86_64. I dont understand very well fedora or rpm to figure out what to do next. I come from ubuntu so I am not that familiar with them just yet. Any help will be appreciated :slight_smile:

1 Like

That shouldn’t happen. Did you have a dnf command fail, like an upgrade? That can cause an inconsistent package set.

rpm is not as smart as dnf in the sense that it won’t go looking for dependencies. You must provide them. In this case, try using the no-deps flag, and if that gets dnf to work, we can use dnf to do the next repairs:

rpm -ivh --no-deps /path/to/rpm file
2 Likes

Thank everyone for your suggestions but unfortunately this still hasn’t worked. This is the current result I get when I run ls -lash /lib64/libzck* which seems wrong as well and dnf still doesn’t work:

4.0K lrwxrwxrwx. 1 root root 11 Mar 12 17:01 /lib64/libzck.so -> libzck.so.1

What’s the output of

ls -lash /lib64/libzck*

please? And, what error is dnf throwing now?

The output for ls -lash /lib64/libzck* is posted above

The new output for dnf is

Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.10/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.10/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python3.10/site-packages/libdnf/__init__.py", line 12, in <module>
    from . import conf
  File "/usr/lib64/python3.10/site-packages/libdnf/conf.py", line 13, in <module>
    from . import _conf
ImportError: libzck.so.1: cannot open shared object file: No such file or directory

Ah, silly us. You need to re-install zchunk-libs, not just zchunk-devel. This is because, zchunk-libs contains the versioned shared object, and zchunk-devel simply contains symlinks to it:

$ ls -lash /lib64/libzck* 
  0 lrwxrwxrwx. 1 root root  15 Mar 12 17:02 /lib64/libzck.so.1 -> libzck.so.1.2.1
96K -rwxr-xr-x. 1 root root 94K Mar 12 17:02 /lib64/libzck.so.1.2.1

$ rpm -qf /lib64/libzck.so.1.2.1 
zchunk-libs-1.2.1-1.fc36.x86_64

$ sudo dnf repoquery -l zchunk-devel
/usr/include/zck.h
/usr/lib/libzck.so
/usr/lib/pkgconfig/zck.pc
/usr/share/doc/zchunk-devel
/usr/share/doc/zchunk-devel/zchunk_format.txt

I.e., zchunk-libs is the package that is used to run software that links to it, and zchunk-devel is only required when such software is being built.

1 Like

Haha no worries! It got it fixed so that’s all that matters! I really appreciate the help :slight_smile: Is there any cleanups or check that I can do now that dnf is working to ensure that no other corrupted files exist?

Running sudo rpm -Vai get:

Unsatisfied dependencies for zchunk-devel-1.2.1-1.fc35.x86_64:
	pkgconfig(libzstd) is needed by (installed) zchunk-devel-1.2.1-1.fc35.x86_64

Running dnf update shows me this:

Error: 
 Problem 1: package kernel-modules-extra-5.16.11-200.fc35.x86_64 requires kernel-uname-r = 5.16.11-200.fc35.x86_64, but none of the providers can be installed
  - conflicting requests
 Problem 2: package kernel-5.16.11-200.fc35.x86_64 requires kernel-core-uname-r = 5.16.11-200.fc35.x86_64, but none of the providers can be installed
  - conflicting requests
(try to add '--skip-broken' to skip uninstallable packages)
2 Likes

Edited:

We don’t need the zchunk-devel package. So you can sudo dnf remove zchunk-devel, and that should fix that (a reinstall should pull in the required deps too). Then maybe run sudo rpm -Va again to see if what else it says.

This one is odd. The build looks OK:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1923203

Have you modified your dnf settings in anyway to exclude packages or versionlock them etc?

1 Like

I don’t think I have

My guess would be a failed software update cause it seems to me there are a lot of affected packages that did not update. Running sudo dnf check --duplicates shows me this:

cups-client-1:2.3.3op2-15.fc35.x86_64 is a duplicate with cups-client-1:2.3.3op2-16.fc35.x86_64
cups-libs-1:2.3.3op2-15.fc35.x86_64 is a duplicate with cups-libs-1:2.3.3op2-16.fc35.x86_64
dnf-4.9.0-1.fc35.noarch is a duplicate with dnf-4.11.1-1.fc35.noarch
dnf-data-4.9.0-1.fc35.noarch is a duplicate with dnf-data-4.11.1-1.fc35.noarch
evince-41.3-1.fc35.x86_64 is a duplicate with evince-41.4-1.fc35.x86_64
evince-djvu-41.3-1.fc35.x86_64 is a duplicate with evince-djvu-41.4-1.fc35.x86_64
evince-libs-41.3-1.fc35.x86_64 is a duplicate with evince-libs-41.4-1.fc35.x86_64
evince-previewer-41.3-1.fc35.x86_64 is a duplicate with evince-previewer-41.4-1.fc35.x86_64
evince-thumbnailer-41.3-1.fc35.x86_64 is a duplicate with evince-thumbnailer-41.4-1.fc35.x86_64
iwl7260-firmware-1:25.30.13.0-129.fc35.noarch is a duplicate with iwl7260-firmware-1:25.30.13.0-130.fc35.noarch
iwlax2xx-firmware-20220209-129.fc35.noarch is a duplicate with iwlax2xx-firmware-20220310-130.fc35.noarch
libdnf-0.64.0-1.fc35.x86_64 is a duplicate with libdnf-0.66.0-1.fc35.x86_64
libreoffice-data-1:7.2.5.2-4.fc35.noarch is a duplicate with libreoffice-data-1:7.2.5.2-5.fc35.noarch
libreport-2.15.2-7.fc35.x86_64 is a duplicate with libreport-2.15.2-8.fc35.x86_64
libreport-filesystem-2.15.2-7.fc35.noarch is a duplicate with libreport-filesystem-2.15.2-8.fc35.noarch
libreport-plugin-bugzilla-2.15.2-7.fc35.x86_64 is a duplicate with libreport-plugin-bugzilla-2.15.2-8.fc35.x86_64
libreport-plugin-reportuploader-2.15.2-7.fc35.x86_64 is a duplicate with libreport-plugin-reportuploader-2.15.2-8.fc35.x86_64
libreport-web-2.15.2-7.fc35.x86_64 is a duplicate with libreport-web-2.15.2-8.fc35.x86_64
linux-firmware-20220209-129.fc35.noarch is a duplicate with linux-firmware-20220310-130.fc35.noarch
linux-firmware-whence-20220209-129.fc35.noarch is a duplicate with linux-firmware-whence-20220310-130.fc35.noarch
python3-dnf-4.9.0-1.fc35.noarch is a duplicate with python3-dnf-4.11.1-1.fc35.noarch
python3-dnf-plugins-core-4.0.24-1.fc35.noarch is a duplicate with python3-dnf-plugins-core-4.1.0-1.fc35.noarch
python3-dnf-plugins-extras-common-4.0.15-2.fc35.noarch is a duplicate with python3-dnf-plugins-extras-common-4.0.16-1.fc35.noarch
python3-hawkey-0.64.0-1.fc35.x86_64 is a duplicate with python3-hawkey-0.66.0-1.fc35.x86_64
python3-libdnf-0.64.0-1.fc35.x86_64 is a duplicate with python3-libdnf-0.66.0-1.fc35.x86_64
snapd-selinux-2.54.3-1.fc35.noarch is a duplicate with snapd-selinux-2.54.4-1.fc35.noarch
xen-licenses-4.15.2-1.fc35.x86_64 is a duplicate with xen-licenses-4.15.2-2.fc35.x86_64
Error: Check discovered 27 problem(s)

Do i need to scan every entry from the output or can I filter in some way the output?

2 Likes

Ah, that explains it. Could you try reinstalling all the new ones here from the list, and hopefully that’ll also remove the older ones. If it does not, we’ll need to manually remove them.

Edit: dnf remove --duplicates will do, that’s what package-cleanup --cleandupes does according to the dnf man page.

That should fix most issues—it really does look like an upgrade failed and messed up some packages, so only these packages should be affected.

It gives a lot of info, but we usually only need to focus on any files that aren’t as they should be. From the manual:

 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  attri‐
      bute(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 prevent 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

looking for S, M, 5 should probably be enough for a start.

1 Like

So the dnf remove --duplicates fixed most of the issues. Using dnf update or dnf distro-sync still shows this:

Last metadata expiration check: 0:23:44 ago on Wed 23 Mar 2022 14:17:41 GMT.
Error: 
 Problem 1: package kernel-modules-extra-5.16.11-200.fc35.x86_64 requires kernel-uname-r = 5.16.11-200.fc35.x86_64, but none of the providers can be installed
  - conflicting requests
 Problem 2: package kernel-5.16.11-200.fc35.x86_64 requires kernel-core-uname-r = 5.16.11-200.fc35.x86_64, but none of the providers can be installed
  - conflicting requests
(try to add '--skip-broken' to skip uninstallable packages)

rpm -Va shows some issues as well but I can inverstigate them a bit more with the help of the manual

EDIT:

From a quick glance all files related to the kernel have the S and 5 flags raised

1 Like

Could probably try a reinstall for the kernels? Or remove kernels that you aren’t using? We have 3 installed by default.

1 Like

Thank you very much for this! All the problems have been resolved. Just to summarise for anyone else having a similar issue from an interrupted update:

  1. Download affected rpm package from https://fedora.pkgs.org
  2. Install using rpm -ivh --nodeps --force /path/to/rpm file
  3. Run dnf remove --duplicates to remove conflicting packages
  4. Run dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q) to remove conflicting kernel packages
4 Likes

It looks like you didn’t need it this time, but I wrote this script a few years ago for when dnf remove --duplicates wasn’t an option.