Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1596540 - RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline
Summary: RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Daniel Mach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 1596995 1612357 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-29 08:16 UTC by Bruno Goncalves
Modified: 2019-03-08 14:20 UTC (History)
29 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Bruno Goncalves 2018-06-29 08:16:30 UTC
Description of problem:
After updating dnf from dnf-2.7.5-16.fc29 to dnf-3.0.1-1.fc29 using ansible module, the following error happens:

# dnf install file
Last metadata expiration check: 0:01:36 ago on Fri 29 Jun 2018 08:06:01 UTC.
Package file-5.33-6.fc29.x86_64 is already installed, skipping.
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.6/site-packages/dnf/cli/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 823, in resolve
    len(self._transaction) > 0
  File "/usr/lib/python3.6/site-packages/dnf/db/group.py", line 205, in __len__
    items = self.history.swdb.getItems()
  File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 290, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.6/site-packages/libdnf/transaction.py", line 713, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline

Version-Release number of selected component (if applicable):
dnf-3.0.1-1.fc29
ansible-2.5.3-1.fc29.noarch

How reproducible:
100%

Steps to Reproduce:
1. ansible -m dnf -a "name=dnf state=latest" localhost
2. ansible -m dnf -a "name=file state=present" localhost
3. dnf install file

Comment 1 Bruno Goncalves 2018-06-29 08:17:13 UTC
Reproducer output using ansible verbose

# ansible -m dnf -a "name=dnf state=latest" localhost -vvv
ansible 2.5.3
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.5 (default, Apr 23 2018, 22:53:50) [GCC 8.0.1 20180410 (Red Hat 8.0.1-0.21)]
Using /etc/ansible/ansible.cfg as config file
Parsed /etc/ansible/hosts inventory source with ini plugin
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

META: ran handlers
Using module file /usr/lib/python3.6/site-packages/ansible/modules/packaging/os/dnf.py
<127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: root
<127.0.0.1> EXEC /bin/sh -c 'echo ~root && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707 `" && echo ansible-tmp-1530259557.0275803-275216751665707="` echo /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707 `" ) && sleep 0'
<127.0.0.1> PUT /root/.ansible/tmp/ansible-local-1393tnyxz5qo/tmpwxkwfrpv TO /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707/dnf.py
<127.0.0.1> EXEC /bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707/ /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707/dnf.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '/usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707/dnf.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c 'rm -f -r /root/.ansible/tmp/ansible-tmp-1530259557.0275803-275216751665707/ > /dev/null 2>&1 && sleep 0'
localhost | SUCCESS => {
    "changed": true,
    "invocation": {
        "module_args": {
            "autoremove": null,
            "conf_file": null,
            "disable_gpg_check": false,
            "disablerepo": [],
            "enablerepo": [],
            "installroot": "/",
            "list": null,
            "name": [
                "dnf"
            ],
            "state": "latest"
        }
    },
    "results": [
        "Installed: python3-hawkey-0.15.1-1.fc29.x86_64",
        "Installed: librepo-1.9.0-2.fc29.x86_64",
        "Installed: python3-dnf-3.0.1-1.fc29.noarch",
        "Installed: python2-dnf-3.0.1-1.fc29.noarch",
        "Installed: python2-librepo-1.9.0-2.fc29.x86_64",
        "Installed: python3-librepo-1.9.0-2.fc29.x86_64",
        "Installed: python3-distro-1.3.0-2.fc29.noarch",
        "Installed: python2-libdnf-0.15.1-1.fc29.x86_64",
        "Installed: python3-dnf-plugins-core-3.0.1-1.fc29.noarch",
        "Installed: python2-hawkey-0.15.1-1.fc29.x86_64",
        "Installed: python3-libdnf-0.15.1-1.fc29.x86_64",
        "Installed: dnf-3.0.1-1.fc29.noarch",
        "Installed: libdnf-0.15.1-1.fc29.x86_64",
        "Installed: dnf-data-3.0.1-1.fc29.noarch",
        "Installed: dnf-plugins-core-3.0.1-1.fc29.noarch",
        "Installed: dnf-yum-3.0.1-1.fc29.noarch",
        "Removed: python2-hawkey-0.11.1-5.fc29.x86_64",
        "Removed: libdnf-0.11.1-5.fc29.x86_64",
        "Removed: dnf-2.7.5-16.fc29.noarch",
        "Removed: dnf-data-2.7.5-16.fc29.noarch",
        "Removed: python3-librepo-1.8.1-7.fc29.x86_64",
        "Removed: dnf-yum-2.7.5-16.fc29.noarch",
        "Removed: dnf-plugins-core-2.1.5-4.fc28.noarch",
        "Removed: librepo-1.8.1-7.fc29.x86_64",
        "Removed: python2-librepo-1.8.1-7.fc29.x86_64",
        "Removed: python3-dnf-2.7.5-16.fc29.noarch",
        "Removed: python3-dnf-plugins-core-2.1.5-4.fc28.noarch",
        "Removed: python3-hawkey-0.11.1-5.fc29.x86_64",
        "Removed: python2-dnf-2.7.5-16.fc29.noarch"
    ]
}
META: ran handlers
META: ran handlers


# ansible -m dnf -a "name=file state=present" localhost -vvv

ansible 2.5.3
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.5 (default, Apr 23 2018, 22:53:50) [GCC 8.0.1 20180410 (Red Hat 8.0.1-0.21)]
Using /etc/ansible/ansible.cfg as config file
Parsed /etc/ansible/hosts inventory source with ini plugin
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

META: ran handlers
Using module file /usr/lib/python3.6/site-packages/ansible/modules/packaging/os/dnf.py
<127.0.0.1> ESTABLISH LOCAL CONNECTION FOR USER: root
<127.0.0.1> EXEC /bin/sh -c 'echo ~root && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468 `" && echo ansible-tmp-1530259650.9760249-94935645595468="` echo /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468 `" ) && sleep 0'
<127.0.0.1> PUT /root/.ansible/tmp/ansible-local-15761z1yj8i8/tmppkg8yt30 TO /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468/dnf.py
<127.0.0.1> EXEC /bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468/ /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468/dnf.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c '/usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468/dnf.py && sleep 0'
<127.0.0.1> EXEC /bin/sh -c 'rm -f -r /root/.ansible/tmp/ansible-tmp-1530259650.9760249-94935645595468/ > /dev/null 2>&1 && sleep 0'
localhost | FAILED! => {
    "changed": false,
    "module_stderr": "Package file-5.33-6.fc29.x86_64 is already installed, skipping.\nTraceback (most recent call last):\n  File \"/tmp/ansible_hy736vot/ansible_module_dnf.py\", line 534, in <module>\n    main()\n  File \"/tmp/ansible_hy736vot/ansible_module_dnf.py\", line 530, in main\n    ensure(module, base, params['state'], params['name'], params['autoremove'])\n  File \"/tmp/ansible_hy736vot/ansible_module_dnf.py\", line 451, in ensure\n    if not base.resolve(allow_erasing=allow_erasing):\n  File \"/usr/lib/python3.6/site-packages/dnf/base.py\", line 823, in resolve\n    len(self._transaction) > 0\n  File \"/usr/lib/python3.6/site-packages/dnf/db/group.py\", line 205, in __len__\n    items = self.history.swdb.getItems()\n  File \"/usr/lib/python3.6/site-packages/dnf/db/history.py\", line 290, in swdb\n    self._swdb = libdnf.transaction.Swdb(self.dbpath)\n  File \"/usr/lib64/python3.6/site-packages/libdnf/transaction.py\", line 713, in __init__\n    this = _transaction.new_Swdb(*args)\nRuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE",
    "rc": 1
}


# dnf install file
Last metadata expiration check: 0:01:36 ago on Fri 29 Jun 2018 08:06:01 UTC.
Package file-5.33-6.fc29.x86_64 is already installed, skipping.
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.6/site-packages/dnf/cli/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.6/site-packages/dnf/base.py", line 823, in resolve
    len(self._transaction) > 0
  File "/usr/lib/python3.6/site-packages/dnf/db/group.py", line 205, in __len__
    items = self.history.swdb.getItems()
  File "/usr/lib/python3.6/site-packages/dnf/db/history.py", line 290, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.6/site-packages/libdnf/transaction.py", line 713, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline

Comment 2 Bruno Goncalves 2018-06-29 08:18:01 UTC
# ls /var/lib/dnf/*
/var/lib/dnf/groups.json

/var/lib/dnf/history:
2018-05-20  history-2018-05-20.sqlite  history-2018-05-20.sqlite-journal

/var/lib/dnf/yumdb:
a  b  c  d  e  f  g  G  h  i  j  k  l  m  n  o  p  q  r  s  S  t  u  v  w  x  y  z

Comment 3 Gwyn Ciesla 2018-06-29 14:19:46 UTC
I got hit with this too.

Comment 4 Martin Hatina 2018-07-02 11:27:49 UTC
*** Bug 1596995 has been marked as a duplicate of this bug. ***

Comment 5 Gwyn Ciesla 2018-07-03 17:01:54 UTC
FYI I see a newer build of DNF, but I can't upgrade to it manually because my dnf is broken and I'd have to upgrade the entire python3 stack to 3.7.

Comment 6 Gwyn Ciesla 2018-07-17 15:53:58 UTC
Any updates? This is impeding some of my work on some library upgrades.

Comment 7 Javi Roman 2018-07-18 07:27:15 UTC
Upgrading to Rawhide, according with [1], from stable f28, I'm getting the same error with dnf-3.0.3-2.fc29.noarch:

[vagrant@localhost ~]$ sudo dnf install vim
Last metadata expiration check: 0:10:33 ago on Wed 18 Jul 2018 07:16:25 AM UTC.
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 817, in resolve
    self._transaction = self._goal2transaction(goal)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 725, in _goal2transaction
    ts.add_install(pkg, obs, reason)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 256, in add_install
    ti_new = self.new(new, libdnf.transaction.TransactionItemAction_INSTALL, reason)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 219, in new
    rpm_item = self._pkg_to_swdb_rpm_item(pkg)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 210, in _pkg_to_swdb_rpm_item
    rpm_item = self.history.swdb.createRPMItem()
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 290, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 713, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline




[1] https://fedoraproject.org/wiki/Releases/Rawhide

Comment 8 kevin martin 2018-07-20 19:40:42 UTC
updated today...getting this error now as well.

Comment 9 Gwyn Ciesla 2018-07-24 21:16:03 UTC
Ping?

Comment 10 kevin martin 2018-07-25 16:15:43 UTC
not fixed in dnf-3.0.4-1.  manually downloaded it and it's dependencies today and updated with rpm -Uvh and tried the dnf update again with the same error.

Comment 11 kevin martin 2018-07-25 16:19:21 UTC
unrelated comment:  would be really cool if yum-deprecated could have been used to do the update of DNF but it fails with a bug that "won't be fixed" having to do with dependencies (error is Invalid version flag: if ).

Comment 12 Fedora Blocker Bugs Application 2018-07-28 14:20:30 UTC
Proposed as a Blocker for 29-beta by Fedora user ttorcz using the blocker tracking app because:

 Non-working 'dnf' breaks at least "🔗 Installing, removing and updating software" criteria.

Comment 13 Gwyn Ciesla 2018-08-02 15:16:33 UTC
Any updates? Is this being worked on?

Comment 14 Valdis Kletnieks 2018-08-02 16:18:44 UTC
(In reply to kevin martin from comment #11)
> unrelated comment:  would be really cool if yum-deprecated could have been
> used to do the update of DNF but it fails with a bug that "won't be fixed"
> having to do with dependencies (error is Invalid version flag: if ).

Actually, it's not a "bug" - it's a new feature in the RPM format that allows conditional pre-requisites.  Before, you could only say "Requires libFooBar > 0.6".  The new format is useful for software that dynamically loads extensions and .so on the fly - you can now say "You don't *need* libFooBar, but if it *is* installed, it has to be > 1.39"

Comment 15 Gwyn Ciesla 2018-08-03 13:20:27 UTC
Makes sense. But having rawhide boxes we can't update, that *is* a bug.

Comment 16 Valdis Kletnieks 2018-08-11 06:11:20 UTC
Seems to be fixed in 3.2.0-2.fc29.  Downloaded the 3 RPMs I needed from koji (dnf, dnf-automatic, dnf-data), installed with 'rpm -Fvh --nodeps', and the result lives long enough to do a 'dnf list updates' and 'dnf update' for the 176 other pending updates.

Is dnf 3.2 in scope for fc29 release? If so, may be able to clear the blocker status.

Comment 17 Tomasz Torcz 2018-08-11 13:25:47 UTC
Re: comment #16
No, it isn't fixed. I've downloaded dnf packages for 3.2.0-2 (along with requirements: python*-hawkey,libdnf, libmodulemd) and the error is still here.
Maybe it's not dnf which is broken (error message makes me think about some glue library between python and C++ code). Could this be fallout from broken binutils?

Comment 18 Tomasz Torcz 2018-08-11 13:30:46 UTC
*** Bug 1612357 has been marked as a duplicate of this bug. ***

Comment 19 Tomasz Torcz 2018-08-11 13:53:13 UTC
This is weird, but I somehow got rid of this error.

I've noticed that PackageKit is crashing with similar error:

Aug 11 15:40:15 sandrider.pipebreaker.pl systemd[1]: Started PackageKit Daemon.
Aug 11 15:40:18 sandrider.pipebreaker.pl packagekitd[36933]: terminate called after throwing an instance of 'SQLite3::LibException'                                      
Aug 11 15:40:18 sandrider.pipebreaker.pl packagekitd[36933]:   what():  Exec failed: no such table: main.trans_cmdline                                                   
Aug 11 15:40:19 sandrider.pipebreaker.pl systemd[1]: packagekit.service: Main process exited, code=dumped, status=6/ABRT

in context of SQLite. So I've checked if sqlite can open dnf database:

 sqlite3 /var/lib/dnf/history/history-2017-07-25.sqlite

Which worked. While I got sql shell, I did 'VACUUM;', because why not?
And afterwards dnf worked again. Seems unlikely, but is it a coincidence?

Comment 20 Valdis Kletnieks 2018-08-11 23:48:13 UTC
(In reply to Tomasz Torcz from comment #17)
> Re: comment #16
> No, it isn't fixed. I've downloaded dnf packages for 3.2.0-2 (along with
> requirements: python*-hawkey,libdnf, libmodulemd) and the error is still
> here.

Oho.

I downloaded *only* the 3 dnf packages (dnf, dnf-automatic, dnf-data) and forced them on with 'rpm --nodeps', and then 'dnf update' pulled in everything else, and things are working on my laptop.

I wonder if the *order* these things get installed matters - if I get dnf 3.2.0 on first, and *then* hawkey and the lib rpms, my system works.  But if Tomasz installs a few more, and they install in a different order it gets broken.

Probably time to 'rpm -q --scripts' the packages Tomasz and I have worked with and see if there's an order-dependent issue.

Comment 21 Valdis Kletnieks 2018-08-12 00:09:17 UTC
Well.  Crap.

Just tried to do a 'dnf update' for the new rawhide rpms.

And the same ka-blammo.

Back to the drawing board.

Comment 22 Gwyn Ciesla 2018-08-13 21:37:36 UTC
(In reply to Tomasz Torcz from comment #19)
> This is weird, but I somehow got rid of this error.
> 
> I've noticed that PackageKit is crashing with similar error:
> 
> Aug 11 15:40:15 sandrider.pipebreaker.pl systemd[1]: Started PackageKit
> Daemon.
> Aug 11 15:40:18 sandrider.pipebreaker.pl packagekitd[36933]: terminate
> called after throwing an instance of 'SQLite3::LibException'                
> 
> Aug 11 15:40:18 sandrider.pipebreaker.pl packagekitd[36933]:   what():  Exec
> failed: no such table: main.trans_cmdline                                   
> 
> Aug 11 15:40:19 sandrider.pipebreaker.pl systemd[1]: packagekit.service:
> Main process exited, code=dumped, status=6/ABRT
> 
> in context of SQLite. So I've checked if sqlite can open dnf database:
> 
>  sqlite3 /var/lib/dnf/history/history-2017-07-25.sqlite
> 
> Which worked. While I got sql shell, I did 'VACUUM;', because why not?
> And afterwards dnf worked again. Seems unlikely, but is it a coincidence?

THIS WORKS. I did this, and it started working.

Comment 23 Valdis Kletnieks 2018-08-13 22:29:33 UTC
Unfortunately, the sqlite3 trick didn't work here.. Even tried moving the contents of /var/lib/dnf/history out of the way and 'dnf clean metadata' and still throws a segfault...

gdb says:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcdaf86fd4b in libdnf::TransactionItem::saveReplacedBy() () at /usr/include/c++/8/bits/shared_ptr_base.h:996
996	      _M_get() const noexcept
Missing separate debuginfos, use: dnf debuginfo-install python3-3.7.0-4.fc29.x86_64
(gdb) where
#0  0x00007fcdaf86fd4b in libdnf::TransactionItem::saveReplacedBy() (this=0x55bb1f7ffd70)
    at /usr/include/c++/8/bits/shared_ptr_base.h:996
#1  0x00007fcdaf87c66a in libdnf::swdb_private::Transaction::saveItems() (this=0x55bb1f762c10)
    at /usr/src/debug/libdnf-0.17.2-1.fc29.x86_64/libdnf/transaction/private/Transaction.cpp:180
#2  0x00007fcdaf8761a2 in libdnf::TransformerTransaction::begin() (this=0x55bb1f762c10)
    at /usr/src/debug/libdnf-0.17.2-1.fc29.x86_64/libdnf/transaction/private/TransformerTransaction.hpp:38
#3  0x00007fcdaf8761a2 in libdnf::Transformer::transformTrans(std::shared_ptr<SQLite3>, std::shared_ptr<SQLite3>)
    (this=0x7ffe8486c980, swdb=std::shared_ptr<SQLite3> (use count 49, weak count 0) = {...}, history=std::shared_ptr<SQLite3> (use count 2, weak count 0) = {...})
    at /usr/src/debug/libdnf-0.17.2-1.fc29.x86_64/libdnf/transaction/Transformer.cpp:226
#4  0x00007fcdaf87789e in libdnf::Transformer::transform() (this=0x7ffe8486c980)
    at /usr/include/c++/8/ext/atomicity.h:96
#5  0x00007fcdaf86127b in libdnf::Swdb::Swdb(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (this=0x55bb1f52a690, path="/var/lib/dnf/history.sqlite")
    at /usr/src/debug/libdnf-0.17.2-1.fc29.x86_64/libdnf/transaction/Swdb.cpp:499
(gdb) print *this
$1 = {<libdnf::TransactionItemBase> = {item = std::shared_ptr<libdnf::Item> (use count 1, weak count 0) = {get() = 0x55bb1f7eca10}, repoid = "rawhide", 
    action = libdnf::TransactionItemAction::UPGRADED, reason = libdnf::TransactionItemReason::USER, state = libdnf::TransactionItemState::ERROR}, 
  id = 1380, trans = 0x55bb1f762c10, transID = 0, conn = std::shared_ptr<SQLite3> (use count 49, weak count 0) = {get() = 0x55bb1f7dd970}, 
  replacedBy = std::vector of length 1, capacity 1 = {std::shared_ptr<libdnf::TransactionItem> (empty) = {get() = 0x0}}}

Wonder what 'transactionItemState::ERROR' is trying to tell me....

Comment 24 Valdis Kletnieks 2018-08-13 22:32:27 UTC
So obviously, the 'exec failed: no such table' problem is fixed, but something else is still busted...

Comment 25 Valdis Kletnieks 2018-08-13 22:43:51 UTC
And the "something else" is bug #1600917  libdnf Segmentation fault after update

I nuked /var/lib/dnf/history entirely, things started working. (merely renaming things in the directory 'mv history-2015-02-12.sqlite history-2015-02-12.sqlite.wombat-stew' didn't work)

Comment 26 Jan Kurik 2018-08-14 09:56:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 27 kevin martin 2018-08-14 13:34:05 UTC
FWIW, Valdis suggestion of nuking history has also worked for me.  my history files dated back to 2014 so maybe there's something missing in the old history sqlite db's or enough has changed over time to make them unusable by the new DNF.

Comment 28 Geoffrey Marr 2018-08-20 19:49:31 UTC
Discussed during the 2018-08-20 blocker review meeting: [1]

The decision to delay the classification of this as a bug was made as we are worried about this and similar bugs that seem to affect some but not other users on upgrade to DNF 3, but do not have sufficient information yet to make a good decision on whether they should be blockers. We will directly request evaluation of this by the dnf team and discuss it again after that.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-08-20/f29-blocker-review.2018-08-20-16.00.txt

Comment 29 Rich Jerrido 2018-08-21 22:56:20 UTC
(In reply to kevin martin from comment #27)
> FWIW, Valdis suggestion of nuking history has also worked for me.  my
> history files dated back to 2014 so maybe there's something missing in the
> old history sqlite db's or enough has changed over time to make them
> unusable by the new DNF.

Same here. Removing /var/lib/dnf/history restored DNF to working order.

Comment 30 Daniel Mach 2018-08-27 14:09:25 UTC
Reproducer in clean environment:

docker run -it fedora:28 /bin/bash
dnf install ansible -y
dnf update fedora-release --releasever=29 -y
ansible -m dnf -a "name=dnf state=latest" localhost
ansible -m dnf -a "name=file state=present" localhost


We'll get it fixed ASAP.

Comment 31 Daniel Mach 2018-08-27 14:27:08 UTC
Now I'm getting this failure after running following step:

% ansible -m dnf -a "name=dnf state=latest" localhost
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

localhost | FAILED! => {
    "changed": false, 
    "msg": "Could not import the dnf python module. Please install `python2-dnf` package."
}


Any idea what could went wrong?
Everything indicates that the package is on the system.
$ rpm -q python2-dnf
python2-dnf-3.2.0-2.fc29.noarch

Comment 32 Bruno Goncalves 2018-08-29 07:23:43 UTC
That's interesting, I'm using Rawhide compose and it seems to work for me...

# ansible -m dnf -a "name=dnf state=latest" localhost -vv
ansible 2.6.3
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.7.0 (default, Aug 17 2018, 17:29:38) [GCC 8.2.1 20180801 (Red Hat 8.2.1-2)]
Using /etc/ansible/ansible.cfg as config file
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

META: ran handlers
localhost | SUCCESS => {
    "changed": false,
    "msg": "Nothing to do"
}
META: ran handlers
META: ran handlers


#####
Note that on Rawhide it uses python3, could be that instead of python2-dnf it actually requires python3-dnf?

I have installed:
python2-dnf-3.2.0-2.fc29.noarch
python3-dnf-3.2.0-2.fc29.noarch

Comment 33 Alexander Mayorov 2018-08-30 15:24:47 UTC
With fc29 upgrade all update and history dnf operations have been falled in to 'Segmentation fault' after
--> Starting dependency resolution

After the recommended above 'rm -rf /var/lib/dnf/history/*'
the new '/var/lib/dnf/history.sqlite' has been created during next 'dnf update' with no any further failure.


Replacement of the old ./history/history-2014-09-09.sqlite with the new ./history.sqlite results in topic starter fault:
$ mv ./history.sqlite ./history/history-2014-09-09.sqlite
$ dnf upgrade
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 816, in resolve
    len(self._transaction) > 0
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 205, in __len__
    items = self.history.swdb.getItems()
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 290, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 713, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline

$ dnf history list
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 95, in _main
    cli.configure(list(map(ucd, args)), option_parser())
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 915, in configure
    self.command.configure()
  File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 849, in configure
    if not os.access(self.base.history.path, os.R_OK):
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 308, in path
    return self.swdb.getPath()
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 290, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 713, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline


Replacement of the new ./history.sqlite file with the my old ./history/history-2014-09-09.sqlite led me to the following update outcome:
$ cp -a ./history/history-2014-09-09.sqlite ./history.sqlite
$ dnf upgrade
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 816, in resolve
    len(self._transaction) > 0
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 205, in __len__
    items = self.history.swdb.getItems()
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 745, in getItems
    return _transaction.Swdb_getItems(self)
RuntimeError: C++ std::exception: Statement: no such table: trans_item in
SELECT   ti.id,   ti.action,   ti.reason,   ti.state,   r.repoid,   i.item_id,   i.name,   i.epoch,   i.version,   i.release,   i.arch FROM   trans_item ti,   repo r,   rpm i WHERE   ti.trans_id = ?   AND ti.repo_id = r.id   AND ti.item_id = i.item_id

$ sudo dnf history list
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
    cli.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1051, in run
    return self.command.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 983, in run
    ret = self.output.historyListCmd(self.transaction_ids)
  File "/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 1518, in historyListCmd
    tids = self._history_list_transactions(extcmds)
  File "/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 1480, in _history_list_transactions
    old = self.history.last()
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 316, in last
    t = self.swdb.getLastTransaction()
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 748, in getLastTransaction
    return _transaction.Swdb_getLastTransaction(self)
RuntimeError: C++ std::exception: Statement: no such table: trans in

        SELECT
            id
        FROM
            trans
        ORDER BY
            id DESC
        LIMIT 1


Then I listed tables in both history*.sqlite:
-- old
$ sqlite3 /var/lib/dnf/history.bak/history-2014-09-09.sqlite ".tables"
pkg_rpmdb             trans_end             trans_with_pkgs
pkg_yumdb             trans_error           vtrans_data_pkgs
pkgtups               trans_prob_pkgs       vtrans_prob_pkgs2
trans_beg             trans_rpmdb_problems  vtrans_skip_pkgs
trans_cmdline         trans_script_stdout   vtrans_with_pkgs
trans_data_pkgs       trans_skip_pkgs

 - new
$ sqlite3 /var/lib/dnf/history.sqlite ".tables"
comps_environment        console_output           trans
comps_environment_group  item                     trans_item
comps_group              item_replaced_by         trans_with
comps_group_package      repo
config                   rpm

It is visible that the old history-2014-09-09.sqlite file really does not have expected tables trans_item, repo, rpm
while the new history.sqlite does not have 

A result of dnf operations depends on path to history.sqlite file and it's format.
Currently the only worked format is the automatically created the new
/var/lib/dnf/history.sqlite

Comment 34 Alexander Mayorov 2018-08-30 15:51:22 UTC
(Fixed tail of comment #33)

It is visible that the old history-2014-09-09.sqlite file really does not have expected tables trans, trans_item, repo, rpm
while the new history.sqlite does not have trans_cmdline.

A result of dnf operations depends on path to history.sqlite file and it's format.
Currently the only worked format is the automatically created the new
/var/lib/dnf/history.sqlite

Comment 35 Geoffrey Marr 2018-09-04 19:53:53 UTC
Discussed during the 2018-09-04 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-09-04/f29-blocker-review.2018-09-04-16.01.txt

Comment 36 Daniel Mach 2018-09-11 14:18:04 UTC
I'm afraid I'm still unable to reproduce it with any combination of RPMs and versions of Fedora on my laptop in a docker container.

DNF has changed a lot in the meantime.
Is someone still able to trigger the exception using the latest DNF available in F29 (eventually in updates-testing)?

If you're able to reproduce it, could you place your old history database[1] to a docker image and try to reproduce it again in a clean environment?

If it fails in docker, could you share your old history database[1] either by attaching to this bug or sending it to me via email incl. the reproducer?

[1] /var/lib/dnf/history/history-YYYY-MM-DD.sqlite



I'll also sync up with lorax and anaconda teams to get dnf-3.5.1 (currently in Rawhide) with all related packages built - it fixes many problems with modularity and is generally more stable than anything that's in F29 now.

Comment 37 Adam Williamson 2018-09-11 18:23:22 UTC
OK, thanks for the update. This was made a blocker to some extent on the basis that it was a clearly identifiable bug that you seemed concerned about, in comment #30. Since it seems that was not actually the case, it may change the blocker evaluation.

I was also told you think that the bug may only have been triggered by upgrading through the 3.0 release series. This would also be significant, as if it's the case, there's really no benefit to blocking the Beta release for this bug at all. Is that the case?

Comment 38 Matthew Miller 2018-09-11 19:01:01 UTC
I also can't reproduce with the steps in comment #30. I'll see if I can with an old history file dropped into place.

Comment 39 Matthew Miller 2018-09-11 19:22:02 UTC
Also can't reproduce with the history file from my F28 system.  Alexander Mayorov  can you attach your history file?

Comment 40 Matthew Miller 2018-09-11 19:24:32 UTC
FWIW, putting junk in the history sqlite file reliably results in a crash (with predictable "sqlite3.DatabaseError: file is not a database")

Comment 41 Matthew Miller 2018-09-11 19:33:41 UTC
FWIW, putting junk in the history sqlite file reliably results in a crash (with predictable "sqlite3.DatabaseError: file is not a database").

Soooo, I can _kind of_ reproduce by replacing /var/lib/dnf/history.sqlite in the fedora:29 docker with history-2018-03-07.sqlite from the fedora:26 docker image. 

Then I get

   RuntimeError: C++ std::exception: Statement: no such table: trans_item in

Does that... help?

Comment 42 Matthew Miller 2018-09-11 20:09:22 UTC
Updating straight from F26 to F29 via DNF in a container seems to work fine. If i just copy the whole history dir from an f26 system to f29, that is completely ignored in favor of creating a new history.sqlite, so I'm not quite sure how to get into the "bad" state.

It seems like DNF should be robust in the case of an unexpected file format -- but I don't think that's a blocker.

Comment 43 Valdis Kletnieks 2018-09-11 20:29:50 UTC
(In reply to Matthew Miller from comment #40)
> FWIW, putting junk in the history sqlite file reliably results in a crash
> (with predictable "sqlite3.DatabaseError: file is not a database")

That is bug bug #1600917 if it's tossing a segfault very early on, which is a different issue than this one "RuntimeError: C++ std::exception: Exec failed:".

Basically, if you have anything with the name history.sqlite (including a valid one from dnf < 3.0) you hit a segfault at startup. Once you nuke the history.sqlite then dnf lives long enough to hit the "Exec failed" error.

As far as I can tell, if you manage to get to dnf 3.2 via some means and nuke the history.sqlite then things more or less work (though see bugs #1626741 and #1620275). Having said that, it's unclear to me how to fix a system that's at a borked level of dnf.  If we've never let a borked version outside the 'rawhide' stream, maybe we can sweep that issue under the rug?

Comment 44 Adam Williamson 2018-09-12 02:17:40 UTC
I have a /var/lib/dnf/history.sqlite on this system - as well as /var/lib/dnf/history.sqlite-journal and /var/lib/dnf/history/history-2013-12-15.sqlite and /var/lib/dnf/history/2013-12-15/(lots of subdirs) - and dnf 3 works fine. I'm on 3.3.0-2.fc29 right now, but I was on 3.0.1-1.fc29 at one point (I may have had even earlier builds in the 3.x series) and I never ran into this. I don't think it's as simple to reproduce as just 'have some old history then update to dnf 3.0'.

Comment 45 Adam Williamson 2018-09-12 02:40:12 UTC
With ACKs from sgallagh, mboddu, nirik and cmurf, I'm bumping this back to proposed blocker. It seems the circumstances have changed sufficiently since we accepted it as a blocker to justify this.

The consequence of this is that we can run an RC compose (as this was the last bug preventing that). We cannot *ship* it, however, unless we explicitly reject it as a blocker (or it's fixed and we run another compose with the fix). That decision will likely be made at the Go/No-Go meeting on Thursday.

Obviously it would still be great if someone figures out what's going on here and a fix for it.

Comment 46 Adam Williamson 2018-09-14 03:52:06 UTC
Re-discussed at 2018-09-13 Fedora 29 Beta Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-09-13/f29-beta-go_no_go-meeting.2018-09-13-17.00.html . We agreed we're all still somewhat concerned that folks ran into this, but no-one has a reproducer or even a plausible theoretical explanation of this, and quite a lot of people tried. So on that basis we decided we can no longer really take it as a blocker. If a more clear reproducer or at least understanding of the bug emerges, we can discuss it again.

Comment 47 Alexander Mayorov 2018-09-14 05:31:16 UTC
(In reply to Matthew Miller from comment #39)
> Also can't reproduce with the history file from my F28 system.  Alexander
> Mayorov  can you attach your history file?

Sorry for a delay.
My system has many upgrades even can't recall an initial version. History database had been migrated from yum.

An archive with my dnf history is about 20MB. How can I transfer it to the thread or to a reproducer?

Comment 48 Daniel Mach 2018-09-20 14:00:41 UTC
I believe that just having the history file available would be a good start.
I could run dnf on it in an isolated environment and if it crashes, we have everything we need. I'll ask for more details otherwise. 

If it's smaller than 20 000 kB, then it should be possible to attach it to this bug. Another option is to use google drive or something similar and paste the link here. Or email it to me: dmach@redhat.com

Comment 49 Alexander Mayorov 2018-09-27 11:15:41 UTC
(In reply to Daniel Mach from comment #48)
> I believe that just having the history file available would be a good start.
> I could run dnf on it in an isolated environment and if it crashes, we have
> everything we need. I'll ask for more details otherwise. 
> 
> If it's smaller than 20 000 kB, then it should be possible to attach it to
> this bug. Another option is to use google drive or something similar and
> paste the link here. Or email it to me: dmach@redhat.com

Recently I've sent an e-mail with shared link to my dnf history.
Did you have a chance to take a look into it? Any news there?

Comment 50 Jose Melendez 2018-09-29 15:18:28 UTC
@Alexander Mayarov && Daniel Mayarov:
I can confirm that nuking (I chose to mv) /var/lib/dnf/history solved the problem in F29.

I have a suggestion: Please consider offering this solution automatically when the error occurs to the user (with backup options as appropriate).

It makes no sense to me that this and other such problems keep re-occurring when we upgrade. I did google searches for the last two days on this and found posts going back over ten years with the same complaints that upgrades bork systems like this.

Please advise if you need to see my /var/lib/dnf/history, thanks!

Jose Melendez
//disclosure: I am for hire and am developing a redundant, deduplicating  operating system recovery and hardening system that I call "Operating System as an appliance" @OSaaa(dot)com . . .

Comment 51 Alex 2018-10-10 21:56:27 UTC
dnf-3.6.1-2.fc29.noarch
dnf-utils-3.0.4-1.fc29.noarch
libdnf-0.20.0-1.fc29.x86_64

After upgraded to Fedora 29 Beta, it Doesn't work with my dnf db, size 27MB
And no problem with Fedora 28

           PID: 1510 (dnf)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Thu 2018-10-11 00:53:08 MSK (2s ago)
  Command Line: /usr/bin/python3 /usr/bin/dnf history
    Executable: /usr/bin/python3.7
 Control Group: /user.slice/user-0.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-0.slice
       Session: 1
     Owner UID: 0 (root)
       Boot ID: 2a6187f155f240c28789fbe027077179
    Machine ID: dfce45a0759e4dfc8f14c0fdac21dc0b
      Hostname: fedora29
       Storage: /var/lib/systemd/coredump/core.dnf.0.2a6187f155f240c28789fbe027077179.1510.1539208388000000.lz4
       Message: Process 1510 (dnf) of user 0 dumped core.

                Stack trace of thread 1510:
                #0  0x00007f0b556b185b _ZN6libdnf15TransactionItem14saveReplacedByEv (libdnf.so.2)
                #1  0x00007f0b556be13a _ZN6libdnf12swdb_private11Transaction9saveItemsEv (libdnf.so.2)
                #2  0x00007f0b556b7c42 _ZN6libdnf22TransformerTransaction5beginEv (libdnf.so.2)
                #3  0x00007f0b556b936e _ZN6libdnf11Transformer9transformEv (libdnf.so.2)
                #4  0x00007f0b556a2d3b _ZN6libdnf4SwdbC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (libdnf.so.2)
                #5  0x00007f0b53ec8799 _wrap_new_Swdb__SWIG_1 (_transaction.so)
                #6  0x00007f0b63327563 cfunction_call_varargs (libpython3.7m.so.1.0)
                #7  0x00007f0b633c5656 do_call_core (libpython3.7m.so.1.0)
                #8  0x00007f0b63307506 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
                #9  0x00007f0b633087d7 _PyFunction_FastCallDict (libpython3.7m.so.1.0)
                #10 0x00007f0b633179c6 _PyObject_Call_Prepend (libpython3.7m.so.1.0)
                #11 0x00007f0b63366011 slot_tp_init (libpython3.7m.so.1.0)
                #12 0x00007f0b63378eb9 type_call (libpython3.7m.so.1.0)
                #13 0x00007f0b633c4c05 call_function (libpython3.7m.so.1.0)
                #14 0x00007f0b633085fa function_code_fastcall (libpython3.7m.so.1.0)
                #15 0x00007f0b63327706 property_descr_get (libpython3.7m.so.1.0)
                #16 0x00007f0b633066a5 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0)
                #17 0x00007f0b633bf819 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
                #18 0x00007f0b633085fa function_code_fastcall (libpython3.7m.so.1.0)
                #19 0x00007f0b6332766e property_descr_get (libpython3.7m.so.1.0)
                #20 0x00007f0b633066a5 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0)
                #21 0x00007f0b633bf819 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0)
                #22 0x00007f0b6334e0ca function_code_fastcall (libpython3.7m.so.1.0)
                #23 0x00007f0b633bf461 call_function (libpython3.7m.so.1.0)
                #24 0x00007f0b63307506 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
                #25 0x00007f0b6334e271 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
                #26 0x00007f0b633bf461 call_function (libpython3.7m.so.1.0)
                #27 0x00007f0b6334e0ca function_code_fastcall (libpython3.7m.so.1.0)
                #28 0x00007f0b633bf61c call_function (libpython3.7m.so.1.0)
                #29 0x00007f0b63307506 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
                #30 0x00007f0b6334e271 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
                #31 0x00007f0b633bf61c call_function (libpython3.7m.so.1.0)
                #32 0x00007f0b63307506 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
                #33 0x00007f0b6334e271 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0)
                #34 0x00007f0b633c04ea call_function (libpython3.7m.so.1.0)
                #35 0x00007f0b63307506 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0)
                #36 0x00007f0b633084b3 PyEval_EvalCodeEx (libpython3.7m.so.1.0)
                #37 0x00007f0b633084db PyEval_EvalCode (libpython3.7m.so.1.0)
                #38 0x00007f0b6342cca2 run_mod (libpython3.7m.so.1.0)
                #39 0x00007f0b6342e78a PyRun_FileExFlags (libpython3.7m.so.1.0)
                #40 0x00007f0b6342f988 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0)
                #41 0x00007f0b6343120d pymain_run_file (libpython3.7m.so.1.0)
                #42 0x00007f0b634316e0 _Py_UnixMain (libpython3.7m.so.1.0)
                #43 0x00007f0b62e9f413 __libc_start_main (libc.so.6)
                #44 0x000055a81766608e _start (python3.7)

GNU gdb (GDB) Fedora 8.2-3.fc29
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3.7...Reading symbols from /usr/lib/debug/usr/bin/python3.7-3.7.0-9.fc29.x86_64.debug...done.
done.
Dwarf Error: could not find partial DIE containing offset 0x7d [in module /usr/lib/debug/usr/bin/python3.7-3.7.0-9.fc29.x86_64.debug]

warning: core file may not match specified executable file.
[New LWP 1510]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments
Missing separate debuginfo for /lib64/libuuid.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/8d/b69c2a3b18ef4729d31fd3404955c11a996c10.debug

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments
Missing separate debuginfo for /lib64/librpmbuild.so.8
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/7e/0f454ffa2e53674837cf7b3d3d01c82f0de926.debug

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments
Missing separate debuginfo for /lib64/librpmsign.so.8
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/57/b6292e8e64b1e4df8d074191388d49f9900a8d.debug

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments

warning: Loadable section ".note.gnu.property" outside of ELF segments
Core was generated by `/usr/bin/python3 /usr/bin/dnf history'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0b556b185b in libdnf::TransactionItem::saveReplacedBy (this=0x55a81873c2d0)
    at /usr/include/c++/8/bits/shared_ptr_base.h:996
996     /usr/include/c++/8/bits/shared_ptr_base.h: No such file or directory.

(gdb) bt
#0  0x00007f0b556b185b in libdnf::TransactionItem::saveReplacedBy (this=0x55a81873c2d0)
    at /usr/include/c++/8/bits/shared_ptr_base.h:996
#1  0x00007f0b556be13a in libdnf::swdb_private::Transaction::saveItems (this=this@entry=0x55a818a6afb0)
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/libdnf/transaction/private/Transaction.cpp:200
#2  0x00007f0b556b7c42 in libdnf::TransformerTransaction::begin (this=0x55a818a6afb0)
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/libdnf/transaction/private/TransformerTransaction.hpp:38
#3  libdnf::Transformer::transformTrans (this=0x7ffe36c457e0,
    swdb=std::shared_ptr<SQLite3> (use count 4399, weak count 0) = {...},
    history=std::shared_ptr<SQLite3> (use count 2, weak count 0) = {...})
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/libdnf/transaction/Transformer.cpp:226
#4  0x00007f0b556b936e in libdnf::Transformer::transform (this=this@entry=0x7ffe36c457e0)
    at /usr/include/c++/8/ext/atomicity.h:96
#5  0x00007f0b556a2d3b in libdnf::Swdb::Swdb (this=0x55a8186c4670, path="/var/lib/dnf/history.sqlite")
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/libdnf/transaction/Swdb.cpp:499
#6  0x00007f0b53ec8799 in _wrap_new_Swdb__SWIG_1 (args=<optimized out>)
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/build-py3/bindings/python/CMakeFiles/_transaction.dir/transactionPYTHON_wrap.cxx:13162
#7  _wrap_new_Swdb (self=<optimized out>, args=<optimized out>)
    at /usr/src/debug/libdnf-0.20.0-1.fc29.x86_64/build-py3/bindings/python/CMakeFiles/_transaction.dir/transactionPYTHON_wrap.cxx:13201
#8  0x00007f0b63327563 in cfunction_call_varargs (kwargs=<optimized out>, args=<optimized out>,
    func=<unknown at remote 0x7f0b53f075e8>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:768
#9  PyCFunction_Call (func=<unknown at remote 0x7f0b53f075e8>, args=<optimized out>, kwargs=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:784
#10 0x00007f0b633c5656 in do_call_core (kwdict=0x0, callargs=<unknown at remote 0x7f0b55fb3dd8>,
    func=<unknown at remote 0x7f0b53f075e8>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4611
#11 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3184
#12 0x00007f0b63307506 in _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>,
    locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x0,
    kwcount=<optimized out>, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0,
--Type <RET> for more, q to quit, c to continue without paging--
    name=<unknown at remote 0x7f0b56102270>, qualname=<unknown at remote 0x7f0b53fcba70>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3923
#13 0x00007f0b633087d7 in _PyFunction_FastCallDict (func=<optimized out>, args=0x7ffe36c45c20, nargs=2,
    kwargs=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:367
#14 0x00007f0b633179c6 in _PyObject_Call_Prepend (callable=<unknown at remote 0x7f0b53f12158>, obj=<optimized out>,
    args=<unknown at remote 0x7f0b5358cf98>, kwargs=0x0)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:904
#15 0x00007f0b63366011 in slot_tp_init (self=self@entry=<unknown at remote 0x7f0b532c5f98>,
    args=args@entry=<unknown at remote 0x7f0b5358cf98>, kwds=kwds@entry=0x0)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/typeobject.c:6597
#16 0x00007f0b63378eb9 in type_call (kwds=<optimized out>, args=<unknown at remote 0x7f0b5358cf98>,
    type=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/typeobject.c:911
#17 _PyObject_FastCallKeywords (callable=<unknown at remote 0x55a8184d02d8>, stack=<optimized out>,
    nargs=<optimized out>, kwnames=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:199
#18 0x00007f0b633c4c05 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4589
#19 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3086
#20 0x00007f0b633085fa in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>,
    co=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:283
#21 _PyFunction_FastCallDict (func=<optimized out>, args=0x7f0b560e04f8, nargs=1, kwargs=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:322
#22 0x00007f0b63327706 in property_descr_get (self=<unknown at remote 0x7f0b538c0bd8>,
    obj=<unknown at remote 0x7f0b536194e0>, type=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/descrobject.c:1360
#23 0x00007f0b633066a5 in _PyObject_GenericGetAttrWithDict (obj=<unknown at remote 0x7f0b536194e0>,
    name=<unknown at remote 0x7f0b558d6880>, dict=0x0, suppress=0)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/object.c:1197
#24 0x00007f0b633bf819 in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:2566
#25 0x00007f0b633085fa in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>,
--Type <RET> for more, q to quit, c to continue without paging--
    co=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:283
#26 _PyFunction_FastCallDict (func=<optimized out>, args=0x7f0b55fbe760, nargs=1, kwargs=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:322
#27 0x00007f0b6332766e in property_descr_get (self=<unknown at remote 0x7f0b538c0c28>,
    obj=<unknown at remote 0x7f0b536194e0>, type=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/descrobject.c:1360
#28 0x00007f0b633066a5 in _PyObject_GenericGetAttrWithDict (obj=<unknown at remote 0x7f0b536194e0>,
    name=<unknown at remote 0x7f0b560c7880>, dict=0x0, suppress=0)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/object.c:1197
#29 0x00007f0b633bf819 in _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:2566
#30 0x00007f0b6334e0ca in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>,
    co=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:408
#31 _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x55a81835a128, nargs=1, kwnames=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:408
#32 0x00007f0b633bf461 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4586
#33 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3103
#34 0x00007f0b63307506 in _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>,
    locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x55a818606380,
    kwcount=<optimized out>, kwstep=1, defs=0x7f0b536f2ae0, defcount=1, kwdefs=0x0, closure=0x0,
    name=<unknown at remote 0x7f0b536f5ab0>, qualname=<unknown at remote 0x7f0b536f5af0>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3923
#35 0x00007f0b6334e271 in _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x55a818606368, nargs=3,
    kwnames=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:433
#36 0x00007f0b633bf461 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4586
#37 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3103
#38 0x00007f0b6334e0ca in function_code_fastcall (globals=<optimized out>, nargs=4, args=<optimized out>,
--Type <RET> for more, q to quit, c to continue without paging--
    co=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:408
#39 _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x55a8182d5e40, nargs=4, kwnames=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:408
#40 0x00007f0b633bf61c in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4586
#41 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3117
#42 0x00007f0b63307506 in _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>,
    locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x55a818575c48,
    kwcount=<optimized out>, kwstep=1, defs=0x7f0b536f4e70, defcount=3, kwdefs=0x0, closure=0x0,
    name=<unknown at remote 0x7f0b56077ab0>, qualname=<unknown at remote 0x7f0b56077ab0>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3923
#43 0x00007f0b6334e271 in _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x55a818575c40, nargs=1,
    kwnames=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:433
#44 0x00007f0b633bf61c in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4586
#45 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3117
#46 0x00007f0b63307506 in _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>,
    locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x7f0b56037418,
    kwargs=0x7f0b560ecb70, kwcount=<optimized out>, kwstep=1, defs=0x7f0b536192c8, defcount=1, kwdefs=0x0,
    closure=0x0, name=<unknown at remote 0x7f0b56038bf0>, qualname=<unknown at remote 0x7f0b56038bf0>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3923
#47 0x00007f0b6334e271 in _PyFunction_FastCallKeywords (func=<optimized out>, stack=0x7f0b560ecb68, nargs=1,
    kwnames=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Objects/call.c:433
#48 0x00007f0b633c04ea in call_function (kwnames=<unknown at remote 0x7f0b56037400>, oparg=<optimized out>,
    pp_stack=<synthetic pointer>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:4586
#49 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3132
#50 0x00007f0b63307506 in _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>,
    locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x0,
--Type <RET> for more, q to quit, c to continue without paging--
    kwcount=<optimized out>, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3923
#51 0x00007f0b633084b3 in PyEval_EvalCodeEx (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>,
    args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0,
    closure=0x0) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:3952
#52 0x00007f0b633084db in PyEval_EvalCode (co=co@entry=<unknown at remote 0x7f0b56005780>,
    globals=globals@entry=<unknown at remote 0x7f0b560401b0>, locals=locals@entry=<unknown at remote 0x7f0b560401b0>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/ceval.c:524
#53 0x00007f0b6342cca2 in run_mod (mod=<optimized out>, filename=<optimized out>,
    globals=<unknown at remote 0x7f0b560401b0>, locals=<unknown at remote 0x7f0b560401b0>, flags=<optimized out>,
    arena=<optimized out>) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/pythonrun.c:1035
#54 0x00007f0b6342e78a in PyRun_FileExFlags (fp=0x55a8182d5350, filename_str=<optimized out>, start=<optimized out>,
    globals=<unknown at remote 0x7f0b560401b0>, locals=<unknown at remote 0x7f0b560401b0>, closeit=1,
    flags=0x7ffe36c470d0) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/pythonrun.c:988
#55 0x00007f0b6342f988 in PyRun_SimpleFileExFlags (fp=0x55a8182d5350, filename=<optimized out>, closeit=1,
    flags=0x7ffe36c470d0) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Python/pythonrun.c:430
#56 0x00007f0b6343120d in pymain_run_file (p_cf=0x7ffe36c470d0, filename=<optimized out>, fp=0x55a8182d5350)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Modules/main.c:425
#57 pymain_run_filename (cf=0x7ffe36c470d0, pymain=0x7ffe36c47220)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Modules/main.c:1520
#58 pymain_run_python (pymain=0x7ffe36c47220) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Modules/main.c:2520
#59 pymain_main (pymain=0x7ffe36c47220) at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Modules/main.c:2666
#60 0x00007f0b634316e0 in _Py_UnixMain (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/python3-3.7.0-9.fc29.x86_64/Modules/main.c:2701
#61 0x00007f0b62e9f413 in __libc_start_main (main=0x55a817666050<error reading variable>, argc=3, argv=0x7ffe36c47458,
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe36c47448)
    at ../csu/libc-start.c:308
#62 0x000055a81766608e in _start ()

Comment 52 Luigi Cantoni 2018-10-17 09:06:18 UTC
I too had the problem when I went from F28->F29.
As advised above I did
mv /var/lib/dnf/history away and dnf now appears to work.
Please do as Jose advised and put a hint out when it fails.
That would help many people who appear to now have incompatible versions.
I am sure most people do not need the history so maybe a clean up option could be included to remove very old versions that are not really needed.

Anyway the versions I had are:
Name         : dnf
Version      : 3.6.1
Release      : 2.fc29
Arch         : noarch
Size         : 1.5 M
Source       : dnf-3.6.1-2.fc29.src.rpm
with
Name         : kernel
Version      : 4.18.12
Release      : 300.fc29
Arch         : x86_64
Size         : 0.0
Source       : kernel-4.18.12-300.fc29.src.rpm

New history /var/lib/dnf/history.sqlite appears to have been created.
This is my first update after F28->F29 a bit over a week ago.

Comment 53 Benjamin Holmes 2018-10-28 10:46:46 UTC
Upgrade from F28 to F29 Beta, had the same problem with DNF.

Last metadata expiration check: 0:00:24 ago on Sun 28 Oct 2018 10:39:19 GMT.
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/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 146, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 748, in resolve
    self._transaction = self._goal2transaction(goal)
  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 645, in _goal2transaction
    ts.add_install(pkg, obs, reason)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 256, in add_install
    ti_new = self.new(new, libdnf.transaction.TransactionItemAction_INSTALL, reason)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 219, in new
    rpm_item = self._pkg_to_swdb_rpm_item(pkg)
  File "/usr/lib/python3.7/site-packages/dnf/db/group.py", line 210, in _pkg_to_swdb_rpm_item
    rpm_item = self.history.swdb.createRPMItem()
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: Exec failed: no such table: main.trans_cmdline


The sqlite VACUUM workaround worked for me - was able to run a dnf upgrade after doing that.

Comment 54 Rick van Ek 2018-11-03 13:47:49 UTC
Idem ,  upgraded from 28 => 29 got hit with same problem:

# dnf list
Traceback (most recent call last):
  File "/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
    cli.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1055, in run
    return self.command.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/commands/__init__.py", line 232, in run
    self.opts.packages)
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 402, in output_packages
    columns = _list_cmd_calc_columns(self.output, ypl)
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 105, in _list_cmd_calc_columns
    _add_pkg_simple_list_lens(data, pkg)
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 93, in _add_pkg_simple_list_lens
    rid = len(pkg._from_repo)
  File "/usr/lib/python3.7/site-packages/dnf/package.py", line 84, in _from_repo
    pkgrepo = self.base.history.repo(self)
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 362, in repo
    return self.swdb.getRPMRepo(str(pkg))
  File "/usr/lib/python3.7/site-packages/dnf/db/history.py", line 291, in swdb
    self._swdb = libdnf.transaction.Swdb(self.dbpath)
  File "/usr/lib64/python3.7/site-packages/libdnf/transaction.py", line 729, in __init__
    this = _transaction.new_Swdb(*args)
RuntimeError: Exec failed: no such table: main.trans_cmdline

Comment 55 Rick van Ek 2018-11-10 10:00:43 UTC
Had a Citrix client running on my system, used it for my work. That gives lots of problems.  Noticed slack is also not starting any more. 
This system survived upgrades since Fedora 24, first time these huge problems.

Is there anything I can test to help fixing this quickly??

Comment 56 Raphaël HOAREAU 2018-11-10 10:54:03 UTC
Same problem here on F28 to F29 upgrade.
Did what was told here : (re)move dnf history (/var/lib/dnf/history).
Now works.

Comment 57 Valdis Kletnieks 2018-11-10 13:26:51 UTC
(In reply to Rick van Ek from comment #55)
> Had a Citrix client running on my system, used it for my work. That gives
> lots of problems.  Noticed slack is also not starting any more. 
> This system survived upgrades since Fedora 24, first time these huge
> problems.
> 
> Is there anything I can test to help fixing this quickly??

Slack (and for a while, skypeforlinux) has a known issue.  The root cause is that Slack and Skype are built using Electron, which would totally lose its mind and blow up *very* quickly under glibc 2.28.  The fix is to re-build against a newer Electron.  Slack is aware of the issue, but hasn't shipped a fixed version yet.

The indicator that it's the Electron problem is getting a SIGSEGV at startup, and gdb says the stack traceback has libnode.so in it.

Two references on the issue:

https://answers.microsoft.com/en-us/skype/forum/skype_linux-skype_startms-skype_installms/skype-not-opening-on-fedora-rawhide/c14eb9d2-563d-4697-b77d-077db7d77ffa

https://github.com/electron/electron/issues/13972 - "Prebuilt Electron binaries segfault at startup on Arch Linux with glibc 2.28"

Comment 58 Adam Williamson 2018-11-10 16:28:54 UTC
Rick: just removing the dnf history should make it work again, if you don't mind losing that.

Comment 59 Rick van Ek 2018-11-11 16:56:37 UTC
@Adam,  

Thanks that worked for me, my system is stable again.  Still have to check some things. Citrix is not working for instance, but I installed F27 on an other laptop and that will do.
Some small stuff is crashed, but what the heck it is workable again.

Comment 60 justinacolmena 2018-11-26 23:18:56 UTC
The /var/lib/dnf/history/ trick seems to have worked for me. Upgraded two servers to Fedora 29 from 28. No problem with one, but the other entered an infinite loop upgrading, and I had to stop the process and reboot.

A segfault due to a missing table in a mini database? Outrageous!

Comment 61 Daniel Mach 2019-03-08 14:20:21 UTC
It took me a while to get to a proper reproducer.
After that, fixing the issue was quite simple.

The root cause was that the migration code was looking
for a history file, but did not skip files with a wrong suffix,
such as: /var/lib/dnf/history/history-2018-11-30.sqlite-journal

https://github.com/rpm-software-management/libdnf/pull/695


Note You need to log in before you can comment on or make changes to this bug.