Bug 500205 - cannot complete installation of satellite-5.3 on rhel4 x86_64 with only 32-bit libaio installed
cannot complete installation of satellite-5.3 on rhel4 x86_64 with only 32-bi...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer (Show other bugs)
530
All Linux
high Severity medium
: ---
: ---
Assigned To: Milan Zazrivec
Petr Sklenar
:
Depends On:
Blocks: 456985
  Show dependency treegraph
 
Reported: 2009-05-11 13:04 EDT by Petr Sklenar
Modified: 2009-09-10 16:36 EDT (History)
5 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 16:36:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
full log from db installation (4.45 KB, text/plain)
2009-05-11 13:04 EDT, Petr Sklenar
no flags Details

  None (edit)
Description Petr Sklenar 2009-05-11 13:04:16 EDT
Created attachment 343481 [details]
full log from db installation

Description of problem:
cannot complete installation of satellite-5.3 on xen guest rhel4 

Version-Release number of selected component (if applicable):
Satellite-5.3.0-RHEL4-re20090507.1-x86_64

How reproducible:
always only on xen rhel4

Steps to Reproduce:
1. install latest rhel4U8(todays built - may 11) XEN guest to hosted
2. install Satellite-5.3.0-RHEL4-re20090507.1-x86_64
3. see error
  
Actual results:
error:
SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> oraclerhnsat: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
ERROR:
ORA-12547: TNS:lost contact

Expected results:
db is created

Additional info:
nonxen machine works as expected, I tried two freshly new xen machines one host (host seems stable ...) and bug could be reproduced on both.
Comment 1 Jan Pazdziora 2009-05-11 14:12:32 EDT
Can you run

# rpm -qf /usr/lib/libaio.so.1

# getenforce

# grep AVC /var/log/audit/audit.log

and show the output?
Comment 2 Petr Sklenar 2009-05-12 03:58:38 EDT
Hello,
this is output:

[root@xen79 satellite]# rpm -qf /usr/lib/libaio.so.1
libaio-0.3.105-2
[root@xen79 satellite]# getenforce
Permissive
[root@xen79 satellite]# grep AVC /var/log/audit/audit.log
#nothing, auditd runs
[root@xen79 satellite]#
Comment 3 Jan Pazdziora 2009-05-12 04:33:53 EDT
Devan, the problem is in

$ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' libaio
libaio-0.3.105-2.i386
$
Comment 4 Jan Pazdziora 2009-05-12 04:57:55 EDT
There is a couple of issues here:

- The machine only has libaio installed, but only installed as i386. How did the machine manage to have that package installed in non-primary architecture?

- The package libaio is listed in updates/rhelrpms, without any architecture specified. When the installer decides what packages to install via update, it finds libaio already installed and is happy. The quick fix for this particular package would be to specify libaio.x86_64 in that updates/rhelrpms. However, cleaner way would probably be to always specify (even the primary) architecture to the call to up2date, for all packages.

- The strange thing is that oracle-server-x86_64 Requires libaio, and that package dependence is met. So from rpm POV, the things is happy, and only in runtime the 64bit libaio.so is not found. Shouldn't the oracle-server-x86_64 require 64bit libaio.so so that we catch the problem on rpm install time?

I wonder if we need a more general bugzilla / test which will install all packages from updates/rhelrpms in their i386 variant (up2date --arch=i386 -i) and then install and try running Satellite. I'm affraid we could hit the same issue with many other packages.
Comment 5 Brandon Perkins 2009-05-12 11:30:17 EDT
Cliff and I want to go down the path of:

- The strange thing is that oracle-server-x86_64 Requires libaio, and that
package dependence is met. So from rpm POV, the things is happy, and only in
runtime the 64bit libaio.so is not found. Shouldn't the oracle-server-x86_64
require 64bit libaio.so so that we catch the problem on rpm install time?

So, fixing the spec to make sure the requirement is for the correct package architecture.

Note to QA, I want this tested for both x86_64 and s390x.
Comment 6 Jan Pazdziora 2009-05-12 12:23:23 EDT
Note: I believe this is not Xen-specific, rather it's multilib issue. We might want to update the Summary/Title of this bugzilla accordingly if this hypothesis is confirmed.
Comment 7 Jan Pazdziora 2009-05-12 12:31:04 EDT
(In reply to comment #5)
> 
> So, fixing the spec to make sure the requirement is for the correct package
> architecture.

Note: on RHEL 4, we use the static list of packages in updates/rhelrpms. So fixing the .spec will cause the installation to fail (and thus show the problem earlier) but to address the issue completely, the change to the installer code is also called for.
Comment 8 Jan Pazdziora 2009-05-12 12:31:55 EDT
I also wonder if that libaio package is even needed on external installations. Maybe we need two lists of packages, one for embedded and one for external situation.
Comment 9 Milan Zazrivec 2009-05-14 10:14:23 EDT
oracle-server-* changes, thirdparty.git:

8886a5675c4b5f68b2a70d50ca275c6c989538e6
c52fe8725d396368f59fab06e11d3a9964d7af68
99695be204041643d959a403bd073a5d933c57ec
8db74d048117af3619a765252fa4dec33bf11fbe
Comment 10 Milan Zazrivec 2009-05-15 11:29:28 EDT
installer changes:

spacewalk.git master: b986d9b9e7277d708f280b357d239c5c4682c673
spacewalk.git VADER: cdbbe25938bfe3709c8cdb124a49733545a6d59a
Comment 11 Michael Mráka 2009-05-18 03:54:33 EDT
(In reply to comment #8)
> I also wonder if that libaio package is even needed on external installations.
> Maybe we need two lists of packages, one for embedded and one for external
> situation.  

Yes, that's correct. Moreover there are couple of other requires needed only for embedded db:
compat-db  
libaio  
libstdc++  
m4  
perl(Filesys::Df)  

I'd suggest splitting rhelrpms into one file per directory - i.e. rhelrpms.Satellite and rhelrpms.EmbeddedDB. Plus installer modification of course ;).
Comment 13 Milan Zazrivec 2009-05-30 04:30:19 EDT
oracle-server-*-10.2.0.4-54
Comment 14 Petr Sklenar 2009-06-02 10:29:01 EDT
verified on x8664:

testing procedure:

0. machine x86_64
1. base installation latest rhel48 (there isn't pkgs libaio)
2. Satellite-5.3.0-RHEL4-re20090529.0
3. satellite seem working - can register there , create channels, push pkgs

after installation:

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' libaio
libaio-0.3.105-2.x86_64

# uname -a
Linux gs-bl460cg1-01.rhts.bos.redhat.com 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Comment 15 Petr Sklenar 2009-06-26 05:34:38 EDT
verified also on s390x:
Satellite-5.3.0-RHEL4-re20090623.0 on s390x:
after installation:

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' libaio
libaio-0.3.105-2.s390x
# uname -a
Linux z211.z900.redhat.com 2.6.9-89.EL #1 SMP Mon Apr 20 10:33:26 EDT 2009 s390x s390x s390x GNU/Linux

# tried basic operation
Comment 16 Tomas Lestach 2009-08-14 08:11:37 EDT
1. I registered a RHEL4 x86_64 machine to rhn.stage
2. I run up2date -u
3. I started a sat installation (Satellite-5.3.0-RHEL4-re20090811.0-x86_64)

no libaio issues.
Comment 17 Tomas Lestach 2009-08-14 10:02:06 EDT
Reproducer shall be following:

1. I registered a RHEL4 x86_64 machine to rhn.stage
2. I run up2date -u
3. I installed i386 version of libaio
check:
# rpm -q libaio
libaio-0.3.105-2.i386
4. I started a sat installation (Satellite-5.3.0-RHEL4-re20090811.0-x86_64)
5. Check whether libaio is installed after sat installation:
# rpm -q libaio
libaio-0.3.105-2.i386
libaio-0.3.105-2.x86_64

Sat installer correctly installed also the x86_64 version of libaio. Passed for x86_64!

Note: Before installation I had to install jpackage-utils manually (BZ#517503).
Comment 18 Tomas Lestach 2009-08-17 09:58:15 EDT
Following the same scenario (Comment#17) with s390x:

3.
# rpm -q --queryformat "%{NAME}-%{VERSION}-%{ARCH}\n" libaio 
libaio-0.3.105-i386

4.
# ./<path>/Satellite-5.3.0-RHEL4-re20090814.0/s390x/s390x/install.pl --disconnected --run-updater=yes

5. 
# rpm -q libaio
libaio-0.3.105-2
libaio-0.3.105-2

Arch is not visible, so:
# rpm -q --queryformat "%{NAME}-%{VERSION}-%{ARCH}\n" libaio 
libaio-0.3.105-i386
libaio-0.3.105-s390x

Sat correctly installed also the s390x version of libaio. Passed for s390x!

Stage validated -> RELEASE_PENDING

Note: Because it was a rhts machine, I had to remove yum.rhts package:
# rpm -e yum-2.2.2-1.rhts.EL4
Comment 19 Brandon Perkins 2009-09-10 16:36:47 EDT
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/RHEA-2009-1434.html

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