Bug 1600917
| Summary: | libdnf Segmentation fault after update | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | lukasz.tylski |
| Component: | libdnf | Assignee: | rpm-software-management |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 29 | CC: | bugzilla, djuran, dmach, giampaolo.ferradini, jmracek, ken, mattias.ellert, mluscon, nathanael, prd-fedora, rpm-software-management, samuel.rakitnican, thib, tomek |
| Target Milestone: | --- | Keywords: | Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-29 07:47:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
lukasz.tylski
2018-07-13 11:36:35 UTC
Solved: Renaming/removing /var/lib/dnf/history works. Did you just remove history or was dnf fixed to work with older history format? I'm reopening this bug. I've just upgraded (f28→f29) and DNF started crashing. Removing /var/lib/dnf/history fixes this, but we can't expect users to do that. DNF have to be fixed to work with (or ignore) old history files. dnf-3.5.1-1.fc29.noarch libdnf-0.19.1-3.fc29.x86_64 My DNF history/ dir causing crashes: https://pipebreaker.pl/z/dnf_history.tar.bz2 Please can you confirm that problem still persist with dnf-3.6.0? It is available from copr repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly)? Hmm. So I've upgraded dnf from COPR, restored history/ dir and did an upgrade. Seems fine on the first run. But I've noticed that history got tossed away:
$ dnf history list
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
3 | upgrade | 2018-09-25 16:01 | Upgrade | 8
2 | upgrade dnf | 2018-09-25 15:59 | Upgrade | 11
1 | upgrade https://kojipkgs | 2018-09-25 06:22 | Upgrade | 1
dnf-3.6.1-0.36g7232477b.fc29.noarch
Ok, thanks for the report. Then I believed that the problem is fixed with dnf-3.6.1 No comment on history disappearing, is that made on purpose? I am personally not very happy about that. *** Bug 1632922 has been marked as a duplicate of this bug. *** Tried dnf-3.6.1 with my particular case bug#1598590, history is preserved and there are no database errors on dnf operations. @srakitnican I'm curious - how do you update dnf to 3.6.1 without losing history when dnf itself won't work? Normally db conversion works fine, but it looks like that your original DB was corrupted. You have my original DB in #c4. But, hmm, conversion you say? I did the following: 1. Moved /var/lib/dnf/history/ directory to the side (so I have non-crashing dnf) 2. Installed some package (iwd) from koji, to verify it's working 3. enabled copr 4. Upgraded dnf (using version from copr) 5. Moved original history/ dir back 6. Did and upgrade to verify dnf work. #c12 got me thinking - is there a conversion going at step 4? Does it mean when I get my original history back in 5, there was already converted DB somewhere and my original wasn't use any longer? If yes, then at 6 I wasn't testing if my original DB crash new dnf. How do I undo the conversion? (In reply to Nathanael Noblet from comment #11) > @srakitnican > > I'm curious - how do you update dnf to 3.6.1 without losing history when dnf > itself won't work? With rpm. It is necessary to provide all the dependencies manually, though. A bit of an tedious process if there are many changes. Alternatively, another option which might have worked in my case is to do the update with an older dnf from another release with the help of --installroot option. To trigger db conversion to new format please delete /var/lib/dnf/history.sqlite. Hope that it helps. this should make the fedora 29 release notes. Reopening, my re-test in #c6 was with empty history. Now, when I deleted history.sqlite and put my original (#c4) history/ dir back, dnf crashes: $ LANG=C LC_ALL=C dnf upgrade Last metadata expiration check: 0:10:50 ago on Sat Oct 6 10:08:45 2018. Naruszenie ochrony pamięci (zrzut pamięci) (the translated message is segmentation fault, core dumped). There is no more information, only this in dmesg: [30559.851045] dnf[49241]: segfault at 40 ip 00007f7d23b17cfb sp 00007ffee51ec2a0 error 4 in libdnf.so.2[7f7d23aa4000+e6000] [30559.851053] Code: 00 49 8b 6c 24 68 4d 8b 6c 24 70 4c 39 ed 0f 84 83 00 00 00 0f 1f 00 48 8b 45 00 49 8b 54 24 40 be 01 00 00 00 48 8b 7c 24 38 <4c> 8b 70 40 e8 bc 6a f9 ff 89 c3 85 c0 0f 85 97 00 00 00 48 8b 7c $ rpm -q dnf libdnf dnf-3.6.1-15gaa71348c.fc29.noarch libdnf-0.20.0-12gd58bb2aa.fc29.x86_64 I see 1632177 is fixed. Is this one fixed, too? Can I disable dnf COPR and get back to regular repos?https://www.eea.europa.eu/themes/air/air-quality-index I believe that the problem is fixed in dnf-4.0.9 with libdnf-0:0.22.3. If the problem reappear please open the new bug, because already multiple issues are discussed here. Is this bug causing just a DNF crash, or can it cause the entire system to crash? I am running DNF 4.2.5 on a Fedora 29 KDE, and the entire system froze in the middle of my last update. Not even [Alt + F2/3/etc] worked, nor mouse moving on the screen. After a reset of the mainboard the system seems to run fine, but running `dnf update` gives no update necessary. Am a bit of a noob, and came here from the docs, but I can follow instructions to provide logs or else, in case. My system does come from multiple upgrades. |