Bug 253955
Summary: | 3.2.3 seems to destroy rpm db after transaction failure | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | rawhide | CC: | herrold, james.antill, pmatilai |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-08-23 12:34:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mamoru TASAKA
2007-08-23 06:45:00 UTC
Note: After this failure, only pam-0.99.8.1-5.fc8 remained in rpm entry and the other 180 rpms seemed to have been removed from rpm entry. Well, reproduced again on the following set: ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: WindowMaker i386 0.92.0-14.fc8 koji 1.9 M mc i386 1:4.6.1a-49.20070604cvs.fc8 koji 2.1 M w3c-libwww-devel i386 5.4.1-0.5.20060206cvs.fc8 koji 205 k Updating for dependencies: WINGs-libs i386 0.92.0-14.fc8 koji 309 k w3c-libwww i386 5.4.1-0.5.20060206cvs.fc8 koji 380 k Transaction Summary ============================================================================= More precisely I did yum update on CUI like: # ( LANG=C ; yum -y upgrade --exclude=foo --exclude=baa 2>&1 | tee yum-update.log ) Eek... yum dies in callback function in middle of transaction, that's very deadly indeed. now I am confused. Exiting in the middle of a transaction will DESTROY the rpmdb? What the hell? I've fixed the bug - I have no idea how it wasn't triggered before this - I must have run 100 transactions with this code but I never ran any of them dumping output to a file or tee - I'll add that to the tests to run. Mamoru, if you can easily reproduce / have the demolished rpmdb still available, I'd appreciate if you can tar up the contents of /var/lib/rpm and put somewhere on the net where I can grab it for inspection (do NOT attach here, it's way too big). I'd like to see if what you're seeing is corruption of sorts, or have the entries *really* just gone up the wind. (In reply to comment #5) > Mamoru, if you can easily reproduce / have the demolished rpmdb still available, > I'd appreciate if you can tar up the contents of /var/lib/rpm and put somewhere > on the net where I can grab it for inspection (do NOT attach here, it's way too > big). > I'd like to see if what you're seeing is corruption of sorts, or have the > entries *really* just gone up the wind. Well, actually it seems reproducible when I use yum-3.2.3-1.fc8 with recording transaction log by using tee (as said in comment 2) I put the "destroyed" rpmdb on http://mtasaka.fedorapeople.org/RPM-contain-corrputed.tar.gz (note: 31.8 Mbyte) Here yum tries to update udev units wxsvg-devel xcdroast xmlto yasm zisofs-tools wxsvg (log included in tarball) and after yum transaction failure, rpmdb returns that udev units wxsvg-devel xcdroast xmlto zisofs-tools are not installed. (I have not checked 3.2.3-2.fc8 yet) Thanks, I've downloaded that now so feel free to remove from eating up your quota. I'll have a closer look tomorrow hopefully. Well, actually with 3.2.3-2.fc8 transaction failure seems disappeared. Thanks. Yes, not crashing in middle of transaction helps :) What I'm curious about is the effect on the rpmdb: typically when transaction crashes you get duplicates, not removed entries. |