Red Hat Bugzilla – Bug 249908
traceback when trying to add package to transaction set; dvd install
Last modified: 2013-01-09 21:37:10 EST
Start a dvd install, add a http repo (like the everything tree), get a traceback at some point when trying to add a package to the transaction set. http://jkeating.fedorapeople.org/ana-addrepo-traceback.txt
*** Bug 250693 has been marked as a duplicate of this bug. ***
Bug 250693 happened while attempting to add hunspell-en to the transaction set. No extra repos were added.
Similar result trying to upgrade an F7 system to F8t1. Suspect this may be an RPM bug instead. Definitely doesn't require http repo though.
This only happens on DVD-installations? At least I can't reproduce any problems with the packages mentioned above from rawhide with rpm 4.4.2.1... Where can I find the DVD-image in question - preferrably exploded or loopback mounted to avoid having to download the whole thing (which is not fun when you're not on LAN)?
BTW the things to look out for, or what triggers this in rpm 4.4.2.1 whereas earlier they would've just silently failed and caused problems later on: - package payload being/reporting something strange (something else than "cpio"), can be checked with 'rpm -qp --qf "%{PAYLOADFORMAT}\n" <path/to/package.rpm>' - corrupted signature on package - some other cases such as trying to add the same package twice into the same transaction If this indeed only happens with DVD installs, I would suspect the content on the media to be somehow corrupt. But of course it's possible there's something wrong with rpm that I'm just not seeing here...
It happens with media based installs, which could be nfs isos. Also it's not always the same package, and sometimes the package source is the iso/media, sometimes it's from an added http repo. The same packages are installed fine when using non-iso install methods.
Ok, I can now shed some light on this. First, a reproducer: Install from dvd, otherwise with defaults but choose to customize package set and select everything from the language group. This triggers the case every time here on i386. Secondly, this indeed only happens with media-based installs, with http I can't reproduce it with the same exact package selections. Thirdly, enabling rpm debug spew (well, rpm.RPMLOG_WARNING would've been sufficient) reveals what's going on: D: opening db environment /mnt/sysimage/var/lib/rpm/Packages create:cdb:mpool D: opening db index /mnt/sysimage/var/lib/rpm/Packages create mode=0x0 D: opening db index /mnt/sysimage/var/lib/rpm/Name create mode=0x0 warning: package hunspell-hr = 0.20060607-1.fc7 was already added, skipping hunspell-hr < 0.20060607-1.fc7 This is almost certainly an old issue that has just gone silently unnoticed because rpm-python < 4.4.2.1 didn't check or return error codes from adding packages to ts. Something in the anaconda yuminstall media-handling code is causing same packages to be inserted twice into the transaction which causes rpmtsAddInstallElement() to return error code which gets returned to python in the form of exception now. Now, raising an exception for what rpm thinks of as a warning is a bit extreme perhaps, but it is an error of sorts... Would be better to differentiate between a real failure (such as corrupt package) and warning that rpm can handle by itself, but there's no sane way to do that currently. Rpm's error passing is so screwed up, duh...
*** Bug 251209 has been marked as a duplicate of this bug. ***
I think I see where we're getting the double add from -- will test and see. Would be nice to have this not blow up, though
Fixed in CVS
*** Bug 251865 has been marked as a duplicate of this bug. ***
*** Bug 252308 has been marked as a duplicate of this bug. ***
*** Bug 253919 has been marked as a duplicate of this bug. ***
*** Bug 282601 has been marked as a duplicate of this bug. ***