Bug 500205

Can you run

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

# getenforce

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

and show the output?

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]#

Devan, the problem is in

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

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.

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.

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.

(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.

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.

oracle-server-* changes, thirdparty.git:

8886a5675c4b5f68b2a70d50ca275c6c989538e6
c52fe8725d396368f59fab06e11d3a9964d7af68
99695be204041643d959a403bd073a5d933c57ec
8db74d048117af3619a765252fa4dec33bf11fbe

installer changes:

spacewalk.git master: b986d9b9e7277d708f280b357d239c5c4682c673
spacewalk.git VADER: cdbbe25938bfe3709c8cdb124a49733545a6d59a

(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 ;).

oracle-server-*-10.2.0.4-54

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

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

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.

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).

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

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