Red Hat Bugzilla – Full Text Bug Listing
|Summary:||dep resolution error, pam missing coreutils, triggered by mach|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Noa Resare <noa>|
|Component:||yum||Assignee:||James Antill <james.antill>|
|Status:||CLOSED NOTABUG||QA Contact:||BaseOS QE Security Team <qe-baseos-security>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-09-08 09:49:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Noa Resare 2009-09-05 11:43:19 EDT
Description of problem: The pam %post scriptlet is failing due to missing dependencies found in coreutils under certain conditions (such as those found when trying to init the mock build system for epel5-i386 on an x86_64 system) The description of the mock issue can be found at in Bug 508211 Unfortunately this issue is a bit tricky to reproduce, it seems to depend on specific versions of lots of packages. Version-Release number of selected component (if applicable): yum-3.2.22-20.el5 How reproducible: always Steps to Reproduce: 0. I think this needs to be done on an x86_64 machine 1. Create a minimal /tmp/testroot/yum/yum.conf with two repos http://mirrorlist.centos.org/?release=5&arch=i386&repo=os and http://mirrorlist.centos.org/?release=5&arch=i386&repo=updates 2. yum -v --installroot /tmp/testroot/ install glibc-devel rpm-build 3. Actual results: Installing pam fails with these erorrs: /var/tmp/rpm-tmp.47234: line 6: cat: command not found /var/tmp/rpm-tmp.47234: line 7: rm: command not found /var/tmp/rpm-tmp.47234: line 22: install: command not found /var/tmp/rpm-tmp.47234: line 25: install: command not found error: %post(pam-0.99.6.2-4.el5.i386) scriptlet failed, exit status 127 which seems natural since coreutils gets installed after pam. Expected results: If all the rpm-build deps gets installed but not rpm-build 85 packages instead of 86 gets installed, coreutils gets installed before pam and post doesn't fail Additional info: - If I install the 86 packages manually with rpm this issue does not manifest itself. - If I don't enable the updates repo the bug does not manifest itself.
Comment 1 Noa Resare 2009-09-05 11:47:21 EDT
(Error in the bug title, 'triggered by mach' should be 'triggered by mock')
Comment 2 Noa Resare 2009-09-05 16:23:12 EDT
Created attachment 359881 [details] a list of rpm files that trigger the issue When trying to pinpoint this I have streamlined the reproduce procedure. I have a local rpms directory with the rpms listed in the attached file all fetched from the CentOS 5 i386 repositories. The following command triggers the scriptlet failure: rm -rf /tmp/bug yum -y --disablerepo=* --nogpgcheck --noplugins --installroot /tmp/bug \ install rpms/*rpm
Comment 3 Noa Resare 2009-09-06 09:51:37 EDT
Created attachment 359910 [details] python script that triggers the ordering issue as a regular user The attached script sets up some rpms from a local directory for installation into an empty local root and checks if the pam package gets placed before the coreutils package by yum.YumBase.ts.order() Since it doesn't actually install anything it can be run as an ordinary user. With the help of this script I've been able to reproduce the problematic behavior on an i386 machine as well as on x86_64
Comment 4 Noa Resare 2009-09-08 05:17:46 EDT
Created attachment 360050 [details] invocation of the 'rpm' program that also triggers the issue It turns out that all that yum does is order the rpm packages that it puts into the rpm transaction in an unfortunate way. With a certain ordering of packages, rpm fails to sort coreutils before pam, which triggers the %post error. Fun fact: Being somewhat interested in statistics I actually ran a large number of random orderings of the package list to see how common the bug-triggering ordering is and it turns out that about .3% of the total number of random list orders triggers the issue.
Comment 5 Noa Resare 2009-09-08 05:43:12 EDT
Since it seems I don't have the permissions to change the component of this bug to rpm I have created a new one at Bug 521769 Perhaps we should leave this one open to work around the issue in yum (by perhaps sorting the packages before installation) if a fix in rpm turns out to be hard to do?
Comment 6 seth vidal 2009-09-08 09:49:23 EDT
yum is not going to implement its own transaction ordering. If you've opened a new bug then this will close