Bug 249908 - traceback when trying to add package to transaction set; dvd install
traceback when trying to add package to transaction set; dvd install
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: 250693 251209 251865 252308 253919 282601 (view as bug list)
Depends On:
Blocks: F8Blocker F8Test1
  Show dependency treegraph
Reported: 2007-07-27 16:12 EDT by Jesse Keating
Modified: 2013-01-09 21:37 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-09 10:10:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2007-07-27 16:12:25 EDT
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.

Comment 1 Chris Lumens 2007-08-03 12:44:10 EDT
*** Bug 250693 has been marked as a duplicate of this bug. ***
Comment 2 Will Woods 2007-08-03 14:20:26 EDT
Bug 250693 happened while attempting to add hunspell-en to the transaction set.
No extra repos were added.
Comment 3 Will Woods 2007-08-06 16:54:43 EDT
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.
Comment 4 Panu Matilainen 2007-08-07 02:27:57 EDT
This only happens on DVD-installations? At least I can't reproduce any problems
with the packages mentioned above from rawhide with rpm

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)?
Comment 5 Panu Matilainen 2007-08-07 10:11:40 EDT
BTW the things to look out for, or what triggers this in rpm 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"
- corrupted signature on package
- some other cases such as trying to add the same package twice into the same

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...
Comment 6 Jesse Keating 2007-08-07 10:24:03 EDT
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.
Comment 7 Panu Matilainen 2007-08-08 03:40:56 EDT
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 < 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...
Comment 8 Jeremy Katz 2007-08-08 11:20:26 EDT
*** Bug 251209 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Katz 2007-08-08 15:54:07 EDT
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
Comment 10 Jeremy Katz 2007-08-09 10:10:09 EDT
Fixed in CVS
Comment 11 Chris Lumens 2007-08-13 09:54:20 EDT
*** Bug 251865 has been marked as a duplicate of this bug. ***
Comment 12 Chris Lumens 2007-08-15 11:01:03 EDT
*** Bug 252308 has been marked as a duplicate of this bug. ***
Comment 13 Chris Lumens 2007-08-22 17:49:15 EDT
*** Bug 253919 has been marked as a duplicate of this bug. ***
Comment 14 Chris Lumens 2007-09-07 12:04:58 EDT
*** Bug 282601 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.