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
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
# 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
I got hit with this too.
*** Bug 1596995 has been marked as a duplicate of this bug. ***
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.
Any updates? This is impeding some of my work on some library upgrades.
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
updated today...getting this error now as well.
Ping?
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.
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 ).
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.
Any updates? Is this being worked on?
(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"
Makes sense. But having rawhide boxes we can't update, that *is* a bug.
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.
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?
*** Bug 1612357 has been marked as a duplicate of this bug. ***
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?
(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.
Well. Crap. Just tried to do a 'dnf update' for the new rawhide rpms. And the same ka-blammo. Back to the drawing board.
(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.
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....
So obviously, the 'exec failed: no such table' problem is fixed, but something else is still busted...
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)
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
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.
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
(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.
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.
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
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
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
(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
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
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.
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?
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.
Also can't reproduce with the history file from my F28 system. Alexander Mayorov can you attach your history file?
FWIW, putting junk in the history sqlite file reliably results in a crash (with predictable "sqlite3.DatabaseError: file is not a database")
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?
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.
(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?
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'.
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.
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.
(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?
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
(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 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?
@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 . . .
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 ()
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.
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.
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
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??
Same problem here on F28 to F29 upgrade. Did what was told here : (re)move dnf history (/var/lib/dnf/history). Now works.
(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"
Rick: just removing the dnf history should make it work again, if you don't mind losing that.
@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.
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!
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
Nice hint @Adam: it worked for me! Thanks a lot!
FEDORA-2019-d4b6ede072 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4b6ede072
dnf-4.2.5-4.fc29, dnf-plugins-extras-4.0.4-2.fc29, libdnf-0.31.0-6.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4b6ede072
dnf-4.2.5-4.fc29, dnf-plugins-extras-4.0.4-2.fc29, libdnf-0.31.0-6.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.