Bug 199772 - LSPP: RHEL5 Alpha1 installs both 32- and 64- bit packages on ppc64
LSPP: RHEL5 Alpha1 installs both 32- and 64- bit packages on ppc64
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-07-21 17:02 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-06 11:41:11 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 IBM Bug Proxy 2006-07-21 17:02:57 EDT
LTC Owner is: gjlynx@us.ibm.com
LTC Originator is: gcwilson@us.ibm.com

Contact Information = gcwilson@us.ibm.com or mcthomps@us.ibm.com
---Additional Hardware Info---
ppc64 LPAR
Machine Type = HV4 ppc64
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:
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:
Comment 1 RHEL Product and Program Management 2006-09-22 17:06:08 EDT
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.
Comment 2 Suzanne Yeghiayan 2006-10-03 17:36:52 EDT
Please retest on Beta 1 and provide package list duplicates.
Comment 3 Pete Graner 2006-10-05 14:40:43 EDT
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.

Comment 4 Tomas Mraz 2006-10-06 04:23:17 EDT
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

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.
Comment 8 Tomas Mraz 2006-10-06 11:37:00 EDT
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.
Comment 9 Jeremy Katz 2006-10-06 11:41:11 EDT
This isn't a bug, it's by design so that people can have a _consistent_ and
_predictable_ experience on multilib systems.
Comment 10 Klaus Weidner 2006-10-09 19:08:40 EDT
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.

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