Ask Your Question

database disk image is malformed with dnf on Fedora 29

asked 2019-01-26 03:03:56 -0500

Martin Ueding gravatar image

updated 2019-01-26 03:05:24 -0500

This is a cross-post from, as I still don't know whether this site or the other has a larger Fedora userbase.

For a few days now I could not install updates due to this error:

# env LC_ALL=C dnf update
Last metadata expiration check: 0:18:57 ago on Wed Jan 23 16:16:14 2019.
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 146, in resolving
  File "/usr/lib/python3.7/site-packages/dnf/", line 760, in resolve
    self._transaction = self._goal2transaction(goal)
  File "/usr/lib/python3.7/site-packages/dnf/", line 681, in _goal2transaction
    ts.add_upgrade(pkg, upgraded, obs)
  File "/usr/lib/python3.7/site-packages/dnf/db/", line 269, in add_upgrade
    ti_new =, libdnf.transaction.TransactionItemAction_UPGRADE)
  File "/usr/lib/python3.7/site-packages/dnf/db/", line 222, in new
    reason = self.get_reason(pkg)
  File "/usr/lib/python3.7/site-packages/dnf/db/", line 237, in get_reason
    return self.history.swdb.resolveRPMTransactionItemReason(, pkg.arch, -1)
  File "/usr/lib64/python3.7/site-packages/libdnf/", line 788, in resolveRPMTransactionItemReason
    return _transaction.Swdb_resolveRPMTransactionItemReason(self, name, arch, maxTransactionId)
RuntimeError: Step: database disk image is malformed in

            ti.action as action,
            ti.reason as reason
            trans_item ti
            trans t ON ti.trans_id =
            rpm i USING (item_id)
            t.state = 1
            /* see comment in TransactionItem.hpp - TransactionItemAction */
            AND ti.action not in (3, 5, 7, 10)
            AND = 'python2-rpkg'
            AND i.arch = 'noarch'
        ORDER BY
            ti.trans_id DESC
        LIMIT 1

I found that one shall do these commands in order to fix it, and I tried, but it has not resolved the problem.

  • dnf clean all
  • dnf makecache
  • rpm --buildddb

On Ask Fedora somebody suggested that dnf is not able to recover from that and that one has to repair the SQLite database manually.

I have tried to run the command given,

sqlite3 history-<date>.sqlite ".dump" | sqlite3 history-<new date>.db && rm history-<date>.sqlite

Doing it on /var/lib/dnf/history/history-2015-10-25.sqlite had no effect. Doing it on /var/lib/dnf/history.sqlite resulted in a new error:

# dnf update
Letzte Prüfung auf abgelaufene Metadaten: vor 1:22:29 am Mi 23 Jan 2019 16:39:44 CET.
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/dnf/cli/", line 64, in main
    return _main(base, args ...
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2019-01-26 04:25:30 -0500

villykruse gravatar image

The brutal approach is to remove everything in the directory /var/lib/dnf. Then reinstall one of your packages would cause a new history.sqlite file to be built from scratch. You will, of course, lose all history information so the command dnf list installed will no longer show where packages were installed from.

The directory /var/lib/dnf/history is no longer used in Fedora 29. During upgrade from Fedora 28, dnf will try to transfer the old history to the new history.sqlite file. Only the files history.sqlite, history.sqlite-shm, and history.sqlite-wal is used by the new dnf version.

rpm --buildddb should be rpm --rebuilddb and that rebuilds the rpm database, but not the dnf database. That would not help.

edit flag offensive delete link more


Somehow after a reboot the SELinux stuff was fixed and dumping the database in the /var/lib/dnfdirectory has cured the problem. I was asked by Matt to file a bug report, so there now is

Martin Ueding gravatar imageMartin Ueding ( 2019-01-27 05:18:58 -0500 )edit

Deleting history.sqlite, history.sqlite-shm, history.sqlite-wal files in /var/lib/dnf directory worked for me. Then just run dnf update. Don't delete all files in /var/lib/dnf directory.

chetan gravatar imagechetan ( 2019-02-23 01:04:59 -0500 )edit

Question Tools

1 follower


Asked: 2019-01-26 03:03:56 -0500

Seen: 440 times

Last updated: Jan 26 '19