| Summary: | rpm update breaks rpm | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steven Dake <sdake> | ||||
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | ffesti, jnovy, pmatilai | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-05-08 11:48:28 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Steven Dake
2012-03-15 19:15:46 UTC
Created attachment 570418 [details]
yum update log
rebooting seems to fix the problem.... The "Thread died in Berkeley DB library" error means that rpm was *previously* either crashed or was forcefully kill while it was doing database operations. Logs should give a clue if it was a crash, other than that there's no way of knowing after the fact. To clear that condition, 'rm -f /var/lib/rpm/__db.*' is normally sufficient, and a reboot will do that as a side-effect of sorts. As for what caused it, like said there's no telling after the fact unless logs indicate a crash. Over time there have been all sorts of external causes to this: once upon time it was PackageKit killing its query backend with kill -9, another truly bizarre one involving NetworkManager invoking gdb upon crash and then gdb getting killed while accessing the rpmdb... This is unlikely to have to do with the rpm update itself, but whether it is just an isolated incidence or whether there's a new rpm killer on the loose remains to be seen. If you want to catch future cases of this occurring, see bug 672932 from comment 16 onwards on how to enable tracking it via audit. Since it appears to have been an isolated incident - most likely *something* forcibly killed rpm/yum but there's no telling after the fact if its not reproducable. Actual crashes should be visible in abrt and/or logs. |