Red Hat Bugzilla – Bug 437813
Error running transaction - no reason
Last modified: 2010-10-22 19:18:04 EDT
Description of problem:
A physical media install on a HVM xen guest led to bogus error message. The
message indicated rpm transaction error but not pointing out the reason.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL5.2 Server snap#1 from CDROM
2. Choose all optional packages (except Virtualization)
3. Proceed with the install up to the 5th CD
Error message - see screen shot
Installation proceeds without error
Folks from RTT indicate that they've seen this issue on ppc, s390x and ia64 but
it wasn't reproduce-able.
Joel Granados advised that this could be caused by a faulty package which
crashes the RPM transaction. The package in question most probably is the last
package being added: kde-i18n-Ukrainian in this case.
anaconda.log doesn't indicate anything suspicious. I'll try to reproduce and
post more results.
Xen guest has 4GB of memory (on a machine with 16GB) so that's not a memmory issue.
Created attachment 298272 [details]
screen dump of UI
Reproduced 2 of 2 times. Steps to reproduce:
1) Boot of the first CD (Xen HVM guest, 4GB ram, 1 CPU)
2) Proceed to stage2
3) At package selection screen choose "Select all optional packages" for all
package groups. Deselect only Virtualization (as we're running on Xen).
4) Proceed with install changing discs as required
5) The error happens after the 5th disc is inserted and OK is clicked. Always
ends up at kde-i18n-Ukrainian package.
All ISOs pass checkisomd5 - tested on Dom0
Just ran a loooooong test with
The bug did not appear. This tree is from 06. and the last change to anaconda
for rhel5 was on the 6. This change had nothing to do with the installation of
packages or the rpm stuff (it was done to fsset.py) IMO there is something
going wrong in the distill phase of the tree compose.
I do apologize, the last commit to rhel5 was Mon Mar 17 20:42:15 2008. However
there are only two commits that actually change the code between the 6 and the
17. None of them is rpm related.
I still think its something non-anaconda related.
FYI, the relative commits that I'm talking about are :
The rest are older that thsee four. and two of the four are version changes (no
code changes). so the relevant commits would be 2 and 4.
(In reply to comment #14)
> seeing the bug with RHEL5.2-Server-20080306.0 tree with steps to reproduce from
> comment #3
That was ia64 ISOs. Joel and I will test with i386 and x86_64 as it might be
arch dependent (he hasn't seen it on x86_64).
CDROM install, snap #1: fails on ia64, passes on i386 and x86_64
Could someone provide a list of the packages that anaconda is attempting to
install when it hits the traceback?
Created attachment 298740 [details]
AFAIK, no traceback. just a message. comment 1.
I observed that yuminstall.py does not consider all the rpm.RPMPROB* elements.
I created a updates image in the hope that it will be more informative.
Created attachment 298741 [details]
this is what was added.
Testing with the provided updates.img doesn't lead to any additional info. Still
the same blank error dialog. I can provide anaconda.log if needed.
*** Bug 252353 has been marked as a duplicate of this bug. ***
Created attachment 299175 [details]
list of rpm packages from 0317 tree (split media)
Created attachment 299176 [details]
list of rpm packages from 0320 tree (split media)
Created attachment 299178 [details]
diff between packages lists
I'm examining this diff to see if there were packages that changed from one
disc to another. Any other files to diff, e.g. comps.xml ?
how about distill, did it change?
Still debugging this issue. have no extra information.
with regard to comment 29. I really see no relation between the changes in
anaconda and the transaction issue.
The changes where made to:
isys.c -> network related stuff
fsset.py -> partitioning and disk
iscsi -> internet scsi stuff
net.c -> networkrelated stuff.
these are all things that come before the installation of the packages and have
no direct relationship with the transaction stuff.
(In reply to comment #37)
> also I see in
> FAILED: compose.16 multilib
FAILED: compose.8 iso_sizes
> and two file conflicts. Are these relevant to this case?
*** Bug 437433 has been marked as a duplicate of this bug. ***
(In reply to comment #39)
> And there's nothing on tty3 when you get the error?
I think the last line on the tty3 is the "adding package" message
Created attachment 299733 [details]
the variable screenshot
The behavior I found is quite strange, I have to look a bit more and run some
more tests but just wanted to add an interesting screen shot.
I let the transaction run (yum code) and checked the error variable after the
step, the error var had tow errors. Funny thing is that anaconda has no idea
of the error ever happening. the exception was raised in yum code, it was
caught in anaconda code, but anaconda has no knowledge of what is in the error
variable (that the reason why it doesn't list anything in the error alert
Moreover, the two files that apear in the error message, are the same ones that
appear in the tree checks in the trees.
look for "File conflict"
(In reply to comment #47)
> I could believe that the xulrunner-devel split across discs in the 0317.0 tree
> is the culprit. However, if that's the case, then why did the installation fail
> at or around disc 5? It wouldn't have hit the conflict until disc 7.
I'm actually hitting this on disc 7.
ok, just commited this for rhel5. The error dialog shows the reason for the
relative commit : 8e7302fc9215e566e0562da8e03be87b76e03e55
should pop up in version 126.96.36.199 of anaconda
sorry, thats 188.8.131.52.
*** Bug 436768 has been marked as a duplicate of this bug. ***
Created attachment 300259 [details]
error dialog with the actual reason - file conflict
*** Bug 440637 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.