Description of problem: This issue was found in CentOS 5.3, though I suspect it is also an issue for RHEL as the pam package is not modified. In some cases (ex. when building a chroot via mock) rpm gets the dependency ordering wrong for pam. pam's %post depends on coreutils, but the dependency is stated as: Prereq: coretutils rather than the more accurate: Requires(post): coreutils Version-Release number of selected component (if applicable): The issue exists in at least pam-0.99.6.2-4.el5 How reproducible: Create a mock chroot for i386 with mock from EPEL (for some reason, it doesn't appear to affect real installs, or the x86_architecture). Additional info: See this thread for additional info: http://www.mail-archive.com/centos@centos.org/msg34585.html
I can confirm this behaviour on Rhel5.3 with mock 0.9.14. I would even suggest that the patch be expanded as follows: Requires(pre): grep Requires(post): mktemp, sed, coreutils, /sbin/ldconfig Requires(postun): /sbin/ldconfig
Are you sure this would fix the problem in the install? I don't think so because the same issue appears with fixed pam in Fedora 8 and later. For some reason (possibly some new circular dependencies in the installed packages) the pam is now installed later in a transactions than before. This is not a regression in pam and I don't think change from Prereq to more correct Requires(pre) and Requires(post) will improve the ordering. You can try to patch it on your own and create a repo with the patched pam package, I'd like to see whether this will improve the situation.
Yes, I did the original simple "Requires(post): coreutils" and it worked around the issue. I admit something is strange, as non mock installs get the ordering right, and x86_64 installs (both mock, and anaconda) get the ordering right as well. I should've pointed out in the original report that building i386 chroots on x86_64 exhibits the bug. I haven't tried creating i386 on i386. In the thread I referenced earlier, there is mention[1] of downgrading rpm to the 5.2 version fixing (or avoiding?) the problem. I haven't tried this, as downgrading rpm is not really feasible for us. If it would be helpful, I can show the installation order for various situations. Or if there is any other info I can provide, please let me know. Thanks, Steve [1] http://www.mail-archive.com/centos@centos.org/msg34765.html
i also confirm that adding: Requires(post): coreutils, /sbin/ldconfig solves the problem.
I can also confirm that adding the following the pam.spec file works: Requires(pre): grep Requires(post): mktemp, sed, coreutils, /sbin/ldconfig Requires(postun): /sbin/ldconfig As Steve points out above, I also should have mentioned that I observed the behaviour when try to build a srpm in a Rhel5.3 i386 mock chroot on a Rhel5.3 x86_64 hosts. x86_64 mock builds on the same host work fine. If I can provide info please hesitate to contact me. I will try and reproduce the on a Rhel5.3 i386 host this afternoon. Many thanks, Gareth
I also confirm that the modified Requires by Gareth work in our environment. Tested with modified version of pam-0.99.6.2-4.
I'd like to confirm as well that the suggested additions to pam.spec correct this issue for me. I'm going to use this as the production pam package at my shop.
*** Bug 499048 has been marked as a duplicate of this bug. ***
Panu, when will an official fix for this bug get rolled out? As we all know this is an annoying issue, that should get fixed and it is easily to solve, nevertheless currently, now it's a regression from 5.2 (working) to 5.3 (non- working).
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 therefore 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. http://rhn.redhat.com/errata/RHBA-2009-1358.html