DNF error: Database Disk image is Malformed

Ask Fedora
1

Recently, while updating my system, something started to hang and the update process was cut short during the cleanup (removing files), and currently my system seems to be in a somewhat broken state.

When running sudo dnf update again after the system crash I am greeted with the following error messages:

Updating and loading repositories:
error: SELECT hnum, blob FROM 'Packages': 11: database disk image is malformed
Repositories loaded.
Problem 1: cannot install both LCEVCdec-4.0.1-1.fc42.x86_64 from terra and LCEVCdec-3.3.7-1.fc42.x86_64 from @System
  - installed package libavcodec-1:7.1.1-3.fc42.x86_64 requires liblcevc_dec_api.so.3()(64bit), but none of the providers can be installed
  - cannot install the best update candidate for package LCEVCdec-3.3.7-1.fc42.x86_64
  - problem with installed package
 Problem 2: cannot install both libnpp-1:13.0.0.50-1.fc42.x86_64 from terra and libnpp-1:12.4.1.87-1.fc42.x86_64 from @System
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppicc.so.12()(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppicc.so.12(libnppicc.so.12)(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppidei.so.12()(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppidei.so.12(libnppidei.so.12)(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppif.so.12()(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppif.so.12(libnppif.so.12)(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppig.so.12()(64bit), but none of the providers can be installed
  - installed package libavfilter-1:7.1.1-3.fc42.x86_64 requires libnppig.so.12(libnppig.so.12)(64bit), but none of the providers can be installed
  - cannot install the best update candidate for package libnpp-1:12.4.1.87-1.fc42.x86_64
  - problem with installed package

One issue seems to be the malformed database disk image. I’ve read about some potential fixes for this which did not seem to resolve the issues in my case, namely:

  • The commands yum clean all, yum clean metadata, yum clean dbcache, yum makecache dnf check and dnf distro-sync all did not seem to solve the issues.
    edit: I also tried to run rpm --builddb, as some forum posts mentioned that command, but it seems that the command might have been removed from rpm, because I simply got a unknown option response
  • I also read that I might solve the issue by deleting (renaming/moving) the file /var/lib/dnf/history.sqlite, but this also did not seem to resolve the issue (I did the same for the .sqlite-wal and .sqlite-shm files, once again to no avail).

The second issue I’m having seems to be the fact that some packages are present in two different sources, namely terra and @System.
I’m not fully sure how I should go about resolving this issue, which would be best to prefer (or if its not particularly a case of “the best”).

Also, while I’m vaguely aware of what terra is - to my understanding it simply tries to extend the fedora repository to applications which might not be present in the main repository - I have absolutely no clue what the @System source would be..

EDIT: It seems like the btrfs errors I saw during my earlier inspection have been resolved (most likely at bootup by my system itself).
Also, there is a slight chance that my file system itself is somewhat corrupted after the interrupted update. After the issues started I checked the status of my btrfs file system (from a different machine) and it reported 8 corruptions.

I’m not sure if those issues are related or seperate, I was hoping to be able to fix the dnf issues first and look at the filesystem afterwards, but if they are related that might simply not be possible.

System stats:

             .',;::::;,'.                 -------------------
         .';:cccccccccccc:;,.             OS: Fedora Linux 42 (KDE Plasma Desktop Edition) x86_64
      .;cccccccccccccccccccccc;.          Host: VivoBook_ASUSLaptop X571LI_X571LI (1.0)
    .:cccccccccccccccccccccccccc:.        Kernel: Linux 6.15.9-201.fc42.x86_64
  .;ccccccccccccc;.:dddl:.;ccccccc;.      Uptime: 3 hours, 47 mins
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.     Packages: 2864 (rpm), 15 (flatpak), 7 (snap)
.:ccccccccccccc;KMMc;cc;xMMc;ccccccc:.    Shell: bash 5.2.37
,cccccccccccccc;MMM.;cc;;WW:;cccccccc,    Display (SAMSUNG): 2560x1440 @ 60 Hz in 85" [External] *
:cccccccccccccc;MMM.;cccccccccccccccc:    Display (LGD0563): 1920x1080 @ 60 Hz in 16" [Built-in]
:ccccccc;oxOOOo;MMM0OOk.;cccccccccccc:    DE: KDE Plasma 6.4.3
cccccc;0MMKxdd:;MMMkddc.;cccccccccccc;    WM: KWin (Wayland)
ccccc;XM0';cccc;MMM.;cccccccccccccccc'    WM Theme: Nordic
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;     Theme: Breeze (Nordic) [Qt], Breeze [GTK3]
ccccc;0MNc.ccc.xMMd;ccccccccccccccc;      Icons: breeze [Qt], breeze [GTK3/4]
cccccc;dNMWXXXWM0:;cccccccccccccc:,       Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK3/4]
cccccccc;.:odl:.;cccccccccccccc:,.        Cursor: breeze (24px)
:cccccccccccccccccccccccccccc:'.          Terminal: ghostty 1.1.3
.:cccccccccccccccccccccc:;,..             Terminal Font: AnonymicePro Nerd Font Mono (13.0pt)
  '::cccccccccccccc::;,.                  CPU: Intel(R) Core(TM) i7-10750H (12) @ 5.00 GHz
                                          GPU 1: NVIDIA GeForce GTX 1650 Ti Mobile [Discrete]
                                          GPU 2: Intel UHD Graphics @ 1.15 GHz [Integrated]
                                          Memory: 7.80 GiB / 15.44 GiB (50%)
                                          Swap: 32.00 KiB / 8.00 GiB (0%)
                                          Disk (/): 164.07 GiB / 929.83 GiB (18%) - btrfs
                                          Local IP (wlo1): 192.168.0.126/24
                                          Battery (A32-K55): 100% [AC Connected]
                                          Locale: en_US.UTF-8
2

There is a command that can rebuild the db to match the installed packages. It may potentially cause problems if there are extreme issues, but I have never seen any problems with running it when certain issues appear.
sudo rpm --rebuilddb
Using that command may fix the malformed database disk image error. One reference is here. Can I recreate a corrupted RPM database? - Unix & Linux Stack Exchange

The @System source is installed packages.
The terra repo can be identified with a quick search for terra repo on the internet. It is a 3rd party repo and in many cases those may cause conflicts with packages from the fedora repos. It appears you must have enabled that repo in some way (and potentially installed some packages from there) since it is not part of a fedora installation.

Both problem 1 and problem 2 show conflicts between packages with the same name from fedora and terra. It may resolve the errors if you run the dnf upgrade command with the --disablerepo terra option. A better, long term fix, would be to disable the terra repo and only enable it when you are installing/upgrading packages from that repo explicitly. sudo dnf --setopt=terra.enabled=0. After disabling it this way it can be enabled with the --enablerepo terra option when you wish to use it.

Having corrupted file system in btrfs would be the very first issue I would address, and those cannot be fixed with the file system mounted and active. Boot from a live image to perform those repairs.

Once the file system has been repaired and you are now able to boot the system again then the issues with the rpm database and the package installations can be addressed.

Always address the most critical error first (the btrfs errors).

2 Likes
3

Okay, so I tried the sudo rpm --rebuilddb option, and… it certainly did something.

I’m currently getting status code: 404 errors on all my repository fetches:

$ sudo dnf update
[sudo] password for brendan:
Updating and loading repositories:
 Terra $releasever                               100% [==================] |   4.0   B/s | 240.0   B |  00m00s
>>> Status code: 404 for https://tetsudou.fyralabs.com/metalink?repo=terra$releasever&arch=x86_64 (IP: 172.67.
>>> Status code: 404 for https://tetsudou.fyralabs.com/metalink?repo=terra$releasever&arch=x86_64 (IP: 172.67.
>>> Status code: 404 for https://tetsudou.fyralabs.com/metalink?repo=terra$releasever&arch=x86_64 (IP: 172.67.
>>> Status code: 404 for https://tetsudou.fyralabs.com/metalink?repo=terra$releasever&arch=x86_64 (IP: 172.67.
>>> Status code: 404 for https://tetsudou.fyralabs.com/metalink?repo=terra$releasever&arch=x86_64 (IP: 104.21.

With the nice final error:

Failed to download metadata (metalink: "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=x86_64") for repository "updates": Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=x86_64 (IP: 3.8.95.119)

So it certainly did something, I’m not sure if its an improvement currently though…

edit
Okay, I figured out why this happened. If you look closely, you’ll notice that the refred links have $releasever in there, for some reason one of my previous actions has whiped dnf’s memory of what release version I’m running, cause if I explicitly force a release version sudo dnf --releasever=42 update then I do not get any 404 errors, but I do still suffer from my previous issues.

4

Terra

Terra is a repository that goes beyond what’s available in Fedora. Experience quality and security with the latest packages, or distribute your own software on Fedora and other RPM-based distributions.

Explore

Deactivate the terra repository and see if it is without error then.

5

I made some additions to my post above to add details and other suggestions.

1 Like
6

Temporarily disabeling terra does indeed seem to have resolved my issue with the update failing.

However, is there a specific reason that this issue happened with terra, or would you advice it to be best practice to ALWAYS disable extra repositories by default and only enable them when updating their specific packages?

7

You would need to are the terra maintainers why their repo has issues.

8

The errors tell you why this happened.
Those specific packages have conflicts between the repos.

In general, many 3rd party repos should be disabled and only enabled when necessary.
Having 2 or more repos enabled with the same package names usually presents a problem.
As long as the package names (and files provided even in different packages) do not conflict then there usually is no problem having extra repos enabled.

9

Btw, 404 meamns not found
on the server. It is not affecting your local system.

As @barryascott mentionet , more details you get outside of the Fedora community.

Did you check the link i posted ?

10

yeah, as I mentioned in the edit to my comment, it was due to my system (for some reason) not knowing the releasever, but thats been solved now.

Also, disabeling terra does fix the issue, I do still have to look at why the issue occured in the first place, and the best way to solve it, but that should (hopefully) be relatively straight forewards

11

It seems you had at some point enabled the terra repo. That would have caused the problems with conflicts. We have no way to know when or why that repo was enabled, nor what you may have installed from there. Only you would know that.

The terra repo seems to not be included in gnome software, so it must have been installed manually and not by a simple button click.

You can check what may have been installed from there with one command.
dnf list --installed | grep terra which should show any packages installed from the terra repo.

1 Like
12

The issue is more or less the same that happens from time to time with RPM Fusion as well. Third party repositories must follow Fedora, their packages must be compatible with Fedora, meaning they must ensure all the dependencies are resolved. Once in a while Fedora makes some changes on its side and the maintainers in the third party repository don’t know about it or they don’t have time to update their packages in a timely manner so DNF gives an error. With RPM Fusion you just have to wait.

Of course RPM Fusion is expected to be compatible with Fedora at all times, other thirs parties can provide the support on a “best effort” basis, meaning errors are more probable.

1 Like