LTC Owner is: gjlynx.com LTC Originator is: gcwilson.com Contact Information = gcwilson.com or mcthomps.com ---Additional Hardware Info--- ppc64 LPAR Machine Type = HV4 ppc64 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Perform a minimal RHEL5 install on a ppc64 LPAR. You will see a mixture of 32- and 64- bit packages are installed. ---Problem Description--- Both 32- & 64- bit versions of some packages are installed on 64-bit machines. This can cause problems. For example, if you have the 32-bit version of PAM installed and install the 64-bit version, the 64-bit version of the helper binaries silently overwrite the 32-bit versions. ---Installation and Packaging Component Data--- Install disk info: /dev/sda Install method: Netboot, NFS Install ISO information: RHEL5 alpha1 Userspace tool common name: rpm The userspace tool has the following bit modes: Both Userspace rpm: rpm *Additional Instructions:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering. This request is not yet committed for inclusion in release.
Please retest on Beta 1 and provide package list duplicates.
Reassigning to tmaraz since this is a PAM issue. I think this is fixed I just can't find the bz right now. Thomas can you pls look and make a dup or if not then pls look into this ASAP. I'm marking it as a B2 blocker just to make sure we don't loose it. Thanks
Pete, why this should be a PAM issue? PAM and many other multilib packages contain not only libraries but also binaries. It would be a big packaging change to require all multilib packages to contain just libraries and split everything else to a different subpackages. This problem definitely doesn't affect only PAM and should be probably eventually resolved somehow but I don't think it is RHEL5 material. Also note that the request is to not install both 32 bit and 64 bit packages by default and not to modify packaging of PAM and everything else multilib so probably anaconda is better component.
That minimal install of PPC RHEL 5 Alpha1 installed both ppc and ppc64 PAM and other libraries although for LSPP eval they need just ppc libraries. (The same for x86_64 where minimal install should install only x86_64 libraries and so on.) I don't know if it has been resolved for RHEL5 Beta 1 or recent FC6Tests. I didn't try minimal install recently. If it has been already resolved put it to MODIFIED please.
This isn't a bug, it's by design so that people can have a _consistent_ and _predictable_ experience on multilib systems.
The behavior we saw was that when installing the 64bit PAM library on the ppc64 platform, the working 32bit pam_tally executable binary from the 32bit PAM library was silently overwritten with a nonworking 64bit version. (The login programs use the 32bit versions of the pam_tally.so PAM module, and the data format it uses in /var/log/faillog is incompatible with the 64bit pam_tally program.) The same problem occured on x86_64. That's not what I would call a consistent and predictable experience... Anyway, this issue is moot now, the new pam_tally2 system claims to use a new and word size independent storage format which would fix this issue.