Description of problem: On my current rawhide installation when I am attempting to run commands like 'dnf update', 'dnf update dnf', 'dnf update kernel*' all these commands invariably end up with something like this: Last metadata expiration check: 1:08:48 ago on Tue 04 Sep 2018 05:04:20 PM MDT. Segmentation fault (core dumped) A command like 'dnf list available kernel*' shows me a series of kernel packages from a version 4.19.0-0.rc1.git4.1.fc30 (and some other like kernel-rpm-macros.noarch or kernelshark.x86_64) but an attempted update invariably dumps core. lz4 compressed cores, which collects itself in /var/lib/systemd/coredump, are invariably 226M in size, hence too bit to attach here, but journal recorded traces look as follows: Process 16643 (dnf) of user 0 dumped core. Stack trace of thread 16643: #0 0x00007fca763a8d4b _ZN6libdnf15TransactionItem14saveReplacedByEv (libdnf.so.2) #1 0x00007fca763b566a _ZN6libdnf12swdb_private11Transaction9saveItemsEv (libdnf.so.2) #2 0x00007fca763af1a2 _ZN6libdnf11Transformer14transformTransESt10shared_ptrI7SQLite3ES3_ (libdnf.so.2) #3 0x00007fca763b089e _ZN6libdnf11Transformer9transformEv (libdnf.so.2) #4 0x00007fca7639a27b _ZN6libdnf4SwdbC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (libdnf.so.2) #5 0x00007fca74cf30df n/a (_transaction.so) #6 0x00007fca8409f7d3 PyCFunction_Call (libpython3.7m.so.1.0) #7 0x00007fca84129b2e _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #8 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #9 0x00007fca84080bcb _PyFunction_FastCallDict (libpython3.7m.so.1.0) #10 0x00007fca8408fdc6 _PyObject_Call_Prepend (libpython3.7m.so.1.0) #11 0x00007fca840dc1b1 slot_tp_init (libpython3.7m.so.1.0) #12 0x00007fca840ef949 _PyObject_FastCallKeywords (libpython3.7m.so.1.0) #13 0x00007fca84129139 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #14 0x00007fca840809ea _PyFunction_FastCallDict (libpython3.7m.so.1.0) #15 0x00007fca8409f976 property_descr_get (libpython3.7m.so.1.0) #16 0x00007fca8407ea85 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0) #17 0x00007fca84123db9 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #18 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #19 0x00007fca84080bcb _PyFunction_FastCallDict (libpython3.7m.so.1.0) #20 0x00007fca8408fdc6 _PyObject_Call_Prepend (libpython3.7m.so.1.0) #21 0x00007fca840dc1b1 slot_tp_init (libpython3.7m.so.1.0) #22 0x00007fca840ef949 _PyObject_FastCallKeywords (libpython3.7m.so.1.0) #23 0x00007fca84128a44 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #24 0x00007fca840809ea _PyFunction_FastCallDict (libpython3.7m.so.1.0) #25 0x00007fca8409f8de property_descr_get (libpython3.7m.so.1.0) #26 0x00007fca8407ea85 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0) #27 0x00007fca84123db9 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #28 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #29 0x00007fca840c5971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #30 0x00007fca84123ab4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #31 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #32 0x00007fca840c5971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #33 0x00007fca84123ab4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #34 0x00007fca840c57ca _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #35 0x00007fca84123c69 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #36 0x00007fca840c57ca _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #37 0x00007fca84123c69 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #38 0x00007fca840c57ca _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #39 0x00007fca84123c69 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #40 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #41 0x00007fca840c5971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #42 0x00007fca84123c69 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #43 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #44 0x00007fca840c5971 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #45 0x00007fca84124a85 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #46 0x00007fca8407f8e6 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #47 0x00007fca840808a3 PyEval_EvalCodeEx (libpython3.7m.so.1.0) #48 0x00007fca840808cb PyEval_EvalCode (libpython3.7m.so.1.0) #49 0x00007fca841a99ae run_mod (libpython3.7m.so.1.0) #50 0x00007fca841a9d46 PyRun_FileExFlags (libpython3.7m.so.1.0) #51 0x00007fca841abe08 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0) #52 0x00007fca841ad7a2 pymain_main.constprop.361 (libpython3.7m.so.1.0) #53 0x00007fca841ae0e0 _Py_UnixMain (libpython3.7m.so.1.0) #54 0x00007fca83c1d413 __libc_start_main (libc.so.6) #55 0x00005610e4b3c08a _start (python3.7) -- Subject: Process 16643 (dnf) dumped core -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Process 16643 (dnf) crashed and dumped core. -- -- This usually indicates a programming error in the crashing program and -- should be reported to its vendor as a bug. Version-Release number of selected component (if applicable): dnf-3.3.0-2.fc29 libdnf-0.17.2-1.fc29 How reproducible: so far always (making the installation quite screwed) Additional info: When I run into the problem I had on my rawhide installation dnf-3.2.0-2.fc29 and libdnf-0.17.0-2.fc29. As this was combination made impossible to get any updates via dnf I pulled from koji the latest available versions of these packages and used rpm to update these. Unfortunately this failed to rectify the issue. Even traces recorded in journal did not really changed. The trace above is from the currently installed version of dnf. I tried 'rpm --rebuilddb'. This did not change anything.
dmach: does 'Triaged' mean you know what's going on here? Thanks!
After renaming /var/lib/dnf/history directory to /var/lib/dnf/history.old dnf became usable again. Note that after getting some updates /var/lib/dnf/history was NOT recreated but two new files showed up. Namely /var/lib/dnf/history.sqlite and /var/lib/dnf/history.sqlite-journal (the second one empty after a transaction was complete).
Please can you confirm that latest dnf-3.6.1 with history data backup works correctly? The latest update was mainly focused on problems with new software database including transformation.
Michal, if you're running F29 not Rawhide, an F29 update with dnf 3.6.1 should be coming soonish. We need to shake out some necessary changes in things that use it first. In Rawhide, it's already built, a compose is running now with it included, I'm hopeful it'll succeed.
(In reply to Adam Williamson from comment #4) > Michal, if you're running F29 not Rawhide, I have a rawhide test installation and not F29. > We need to shake out some necessary changes in > things that use it first. In Rawhide, it's already built, It is not entirely clear to me how I am supposed to check this. With dnf-3.6.1 restore /var/lib/dnf/history/ and try what will happen? What I am supposed to do with new files /var/lib/dnf/history.sqlite{,-journal} which were already created (see comment #2)? If 3.6.1 is already available I can try that "soon" but not in this moment.
"It is not entirely clear to me how I am supposed to check this. With dnf-3.6.1 restore /var/lib/dnf/history/ and try what will happen?" Yep. "What I am supposed to do with new files /var/lib/dnf/history.sqlite{,-journal} which were already created" You can move them temporarily and put them back later. I guess you may not be able to get a 'complete' combined history any more, though :( Daniel would know more.
(In reply to Adam Williamson from comment #6) > "It is not entirely clear to me how I am supposed to check this. With > dnf-3.6.1 restore /var/lib/dnf/history/ and try what will happen?" > > Yep. The currently available in repos dnf for rawhide is 3.5.1-2.fc30. After fishing out required packages from three different places on koji AND adding '--allowerasing' to an update command I managed to update dnf to dnf-3.6.1-1.fc30. BTW - this is a bug too. If python2-{dnf,hawkey,libdnf,whatever} packages are no longer needed/present they should be be listed in appropriate packages "Obsoletes". With /var/lib/dnf/history/ restored the first attempt to run an update command resulted in "Segmentation fault (core dumped)" with a core file in /var/lib/systemd/coredump/ of the same size as before and the following stack trace: Sep 27 18:15:20 ... systemd-coredump[2876]: Process 2872 (dnf) of user 0 dumped core. Stack trace of thread 2872: #0 0x00007efc1cef485b _ZN6libdnf15TransactionItem14saveReplacedByEv (libdnf.so.2) #1 0x00007efc1cf0113a _ZN6libdnf12swdb_private11Transaction9saveItemsEv (libdnf.so.2) #2 0x00007efc1cefac42 _ZN6libdnf11Transformer14transformTransESt10shared_ptrI7SQLite3ES3_ (libdnf.so.2) #3 0x00007efc1cefc36e _ZN6libdnf11Transformer9transformEv (libdnf.so.2) #4 0x00007efc1cee5d3b _ZN6libdnf4SwdbC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (libdnf.so.2) #5 0x00007efc1b6c0799 n/a (_transaction.so) #6 0x00007efc2a984fb3 PyCFunction_Call (libpython3.7m.so.1.0) #7 0x00007efc2aa24f83 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #8 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #9 0x00007efc2a96595b _PyFunction_FastCallDict (libpython3.7m.so.1.0) #10 0x00007efc2a975456 _PyObject_Call_Prepend (libpython3.7m.so.1.0) #11 0x00007efc2a9c4121 n/a (libpython3.7m.so.1.0) #12 0x00007efc2a9d74b9 _PyObject_FastCallKeywords (libpython3.7m.so.1.0) #13 0x00007efc2aa245d4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #14 0x00007efc2a96577a _PyFunction_FastCallDict (libpython3.7m.so.1.0) #15 0x00007efc2a985156 n/a (libpython3.7m.so.1.0) #16 0x00007efc2a963735 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0) #17 0x00007efc2aa1ebf9 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #18 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #19 0x00007efc2a96595b _PyFunction_FastCallDict (libpython3.7m.so.1.0) #20 0x00007efc2a975456 _PyObject_Call_Prepend (libpython3.7m.so.1.0) #21 0x00007efc2a9c4121 n/a (libpython3.7m.so.1.0) #22 0x00007efc2a9d74b9 _PyObject_FastCallKeywords (libpython3.7m.so.1.0) #23 0x00007efc2aa23e2f _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #24 0x00007efc2a96577a _PyFunction_FastCallDict (libpython3.7m.so.1.0) #25 0x00007efc2a9850be n/a (libpython3.7m.so.1.0) #26 0x00007efc2a963735 _PyObject_GenericGetAttrWithDict (libpython3.7m.so.1.0) #27 0x00007efc2aa1ebf9 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #28 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #29 0x00007efc2a9ac1b1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #30 0x00007efc2aa1e841 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #31 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #32 0x00007efc2a9ac1b1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #33 0x00007efc2aa1e841 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #34 0x00007efc2a9ac00a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #35 0x00007efc2aa1e9fc _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #36 0x00007efc2a9ac00a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #37 0x00007efc2aa1e9fc _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #38 0x00007efc2a9ac00a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #39 0x00007efc2aa1e9fc _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #40 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #41 0x00007efc2a9ac1b1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #42 0x00007efc2aa1e9fc _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #43 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #44 0x00007efc2a9ac1b1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #45 0x00007efc2aa1f8c8 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #46 0x00007efc2a9646c8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #47 0x00007efc2a965633 PyEval_EvalCodeEx (libpython3.7m.so.1.0) #48 0x00007efc2a96565b PyEval_EvalCode (libpython3.7m.so.1.0) #49 0x00007efc2aa923fe n/a (libpython3.7m.so.1.0) #50 0x00007efc2aa94226 PyRun_FileExFlags (libpython3.7m.so.1.0) #51 0x00007efc2aa956e8 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0) #52 0x00007efc2aa97122 n/a (libpython3.7m.so.1.0) #53 0x00007efc2aa97a60 _Py_UnixMain (libpython3.7m.so.1.0) #54 0x00007efc2abf4413 __libc_start_main (libc.so.6) #55 0x0000561cfff2f08e _start (python3.7) -- Subject: Process 2872 (dnf) dumped core -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Process 2872 (dnf) crashed and dumped core. -- -- This usually indicates a programming error in the crashing program and -- should be reported to its vendor as a bug. After moving again /var/lib/dnf/history/ to /var/lib/dnf/history.old and restoring /var/lib/dnf/history.sqlite dnf works again. So from my end it does not look like that anything changed with respect to this bug.
Python2 packages should be obsoleted by Fedora-obsolete-packages. There is a request in bugzilla for that.
Personally I think it would be good to have obsoletes in dnf somewhere too. fedora-obsolete-packages was only introduced *relatively* recently (in F26, I think); systems upgraded from before it was introduced may not have it installed. I'm also not sure if it's included in minimal installs.
(In reply to Jaroslav Mracek from comment #8) > Python2 packages should be obsoleted by Fedora-obsolete-packages. There is a > request in bugzilla for that. I am afraid that I am not catching how relevant that is here. After all the stack trace explicitely refers all over to python3.7 and segfaults are caused by a presence of a dnf created /var/lib/dnf/history/.
whoops, sorry, I think that discussion was meant for https://bugzilla.redhat.com/show_bug.cgi?id=1600444 .
It looks like that the problem was in conversion old history db to new one (swdb). The conversion was significantly in dnf-4.0.9. I also believe that the improvement also fix the Please could you reproduce the issue with dnf-4.0.9+?
(In reply to Jaroslav Mracek from comment #12) > It looks like that the problem was in conversion old history db to new one > (swdb). The conversion was significantly in dnf-4.0.9. I also believe that > the improvement also fix the Please could you reproduce the issue with > dnf-4.0.9+? My current dnf on a rawhide test installation is 4.2.5-1.fc31. So far 'dnf update' behaves with /var/lib/dnf/history.old renamed back to /var/lib/dnf/history. It appears then that the problem is gone. Also looking at timestamps it appears that my fc29 installations stopped using /var/lib/dnf/history sometime in November 2018. I do not recall of bumping into the issue from this bug on those machines. Lucky with a format?
Thanks a lot for testing. According to comment 13, the issue is resolved. The timestamp is also correct because we start to store history in different file.
(In reply to Jaroslav Mracek from comment #14) > Thanks a lot for testing. According to comment 13, the issue is resolved. I thought so. Only today I got SIGSEGV after 'dnf update' on one fc29 installation with dnf-4.2.5-1.fc29. To get around the issue I renamed /var/lib/dnf/history to /var/lib/dnf/history.old and then 'dnf update' run as expected. After that and "empty" run of 'dnf update' with /var/lib/dnf/history restored did not cause any coredumps. Also two other fc29 installation with a similar configuration survived the same update without any blowups. File 'exploitable' in /var/spool/abrt/ccpp... says: Likely crash reason: Jump to an invalid address Exploitable rating (0-9 scale): 6 An information recorded by journald looks like follows: dnf[27361]: segfault at 55d188b83824 ip 00007fc8a70dd622 sp 00007ffed78c2ec0 error 4 in libsolv.so.1[7fc8a70ae000+76000] Code: 84 ff 78 74 c1 e2 07 48 83 c0 02 31 fa 80 f6 40 48 85 c0 74 54 49 8b 4c 24 58 48 63 d2 48 63 0c 91 49 8b 54 24 68 48 8d 14 8a <8b> 32 85 f6 74 39 49 8b 7c 24 28 48 63 de 48 c1 e3 04 48 01 fb 3b Process 27361 (dnf) of user 0 dumped core. Stack trace of thread 27361: #0 0x00007fc8a70dd622 n/a (libsolv.so.1) #1 0x00007fc8a70de264 repodata_lookup_num (libsolv.so.1) #2 0x00007fc8a70ef2fa solvable_identical (libsolv.so.1) #3 0x00007fc8a70b5154 n/a (libsolv.so.1) #4 0x00007fc8a70c182a solver_solve (libsolv.so.1) #5 0x00007fc8a757a0a5 _ZN6libdnf4Goal4Impl5solveEP7s_Queue14DnfGoalActions (libdnf.so.2) #6 0x00007fc8a757a2e3 _ZN6libdnf4Goal3runE14DnfGoalActions (libdnf.so.2) #7 0x00007fc8a750fe5d hy_goal_run_flags (libdnf.so.2) #8 0x00007fc8a58f1ddf n/a (_hawkey.so) #9 0x00007fc8b54cf7be _PyMethodDef_RawFastCallKeywords (libpython3.7m.so.1.0) #10 0x00007fc8b54cf820 _PyCFunction_FastCallKeywords (libpython3.7m.so.1.0) #11 0x00007fc8b553bf1a _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #12 0x00007fc8b54cec4a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #13 0x00007fc8b55368d4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #14 0x00007fc8b54869f8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #15 0x00007fc8b54cedf1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #16 0x00007fc8b55368d4 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #17 0x00007fc8b54cec4a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #18 0x00007fc8b5536a9c _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #19 0x00007fc8b54cec4a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #20 0x00007fc8b5536a9c _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #21 0x00007fc8b54cec4a _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #22 0x00007fc8b5536a9c _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #23 0x00007fc8b54869f8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #24 0x00007fc8b54cedf1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #25 0x00007fc8b5536a9c _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #26 0x00007fc8b54869f8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #27 0x00007fc8b54cedf1 _PyFunction_FastCallKeywords (libpython3.7m.so.1.0) #28 0x00007fc8b5537972 _PyEval_EvalFrameDefault (libpython3.7m.so.1.0) #29 0x00007fc8b54869f8 _PyEval_EvalCodeWithName (libpython3.7m.so.1.0) #30 0x00007fc8b5487903 PyEval_EvalCodeEx (libpython3.7m.so.1.0) #31 0x00007fc8b548792b PyEval_EvalCode (libpython3.7m.so.1.0) #32 0x00007fc8b55ad9c2 n/a (libpython3.7m.so.1.0) #33 0x00007fc8b55add57 PyRun_FileExFlags (libpython3.7m.so.1.0) #34 0x00007fc8b55b0748 PyRun_SimpleFileExFlags (libpython3.7m.so.1.0) #35 0x00007fc8b55b2531 n/a (libpython3.7m.so.1.0) #36 0x00007fc8b55b276c _Py_UnixMain (libpython3.7m.so.1.0) #37 0x00007fc8b4fe3413 __libc_start_main (libc.so.6) #38 0x000055cfb167708e _start (python3.7) Files core_backtrace from abrtd information and gdb backtrace after python3-debuginfo-3.7.3-3.fc29.x86_64 and libsolv-debuginfo-0.7.5-1.fc29.x86_64 were installed are attached
Created attachment 1587969 [details] File core_backtrace as saved by abrtd
Created attachment 1587970 [details] backtrace from gdb with python3-debuginfo and libsolv-debuginfo present
On a system with dnf which dumped core as per comment 15 I renamed back the old history to /var/lib/dnf/history/ and run recent "real" updates, i.e. with a non-empty set of packages to update. So far no SIGSEGV. Just unlucky?
Please could you provide /var/lib/dnf/history.old?
(In reply to Jaroslav Mracek from comment #19) > Please could you provide /var/lib/dnf/history.old? As I said in comment #18 after this coredump incident I renamed back /var/lib/dnf/history.old to /var/lib/dnf/history/ and so far I run through a number of updates without further fireworks. I can provide a content of this directory but it is on a somewhat bigger side. 'du' reports 32M and even xz-compressed tar archive is 5.5M. Not sure what is the current upper limit for bugzilla attachments but this is likely too big. Some other ways to make it available? Just try to email it to you? A core file dumped by dnf is 144M. :-)
5.5M should be not a problem for bugzilla. Please could you try to attach it?
Created attachment 1592899 [details] archive of old dnf history > 5.5M should be not a problem for bugzilla. Please could you try to attach it? OK, here we go.
BTW - in the meantime on fc29 dnf was updated to 4.2.5-2 with the following entry in Changelog: "Backport patches to enhance synchronization of rpm transaction to swdb".
I tested it with libdnf-0.35.2, the conversion of old DB to SWDB worked well, therefore I can mark it as resolved. Thank you very much for your help. Hope that no other problems appear.