Oracle10g on CentOS 5 x86_64

[d3javu]

Hi all!

I've installed Oracle on a CentOS 5 - x86_64 System.

The installation was fine, but if I start oracle, I got this error:

[quote]
/etc/init.d/oracle start

#############################################################################
# Begin of O R A C L E startup section #
#############################################################################


SETTINGS start from /etc/sysconfig/oracle
- Set Kernel Parameters for Oracle: yes
- Start Oracle OCFS: no
- Start Oracle OCM: no
- Start Oracle GSD: no
- Start Oracle Listener: yes
- Start Oracle Database: yes
- Start Oracle Webserver: no
- Start Oracle CManager: no
- Start Oracle Agent: no
- Start Oracle Internet Filesystem: no
- Start Oracle Directory Manager: no


Setting kernel parameters for Oracle, see file
/etc/sysconfig/oracle for explanations.

Shared memory: SHMMAX=3294967296 SHMMNI=4096 SHMALL=2097152
Semaphore values: SEMMSL=1250 SEMMNS=32000 SEMOPM=100 SEMMNI=256
Other values: FILE_MAX_KERNEL=131072 IP_LOCAL_PORT_RANGE=1024 65000
RMEM_DEFAULT=4194304 WMEM_DEFAULT=262144 RMEM_MAX=4194304 WMEM_MAX=262144
ULIMIT values: MAX_CORE_FILE_SIZE_SHELL=unlimited
FILE_MAX_SHELL=65536 PROCESSES_MAX_SHELL=16384
cat: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32
---- WARNING - SHMMAX could not be set properly ----
Tried to set it to: 3294967296
cat: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32
Value is now:
You might try again with a lower value.

Kernel parameters set for Oracle: done


- Starting Oracle Cluster Filesystem... unused
- Starting Oracle Cluster Manager... unused
- Starting Oracle GSD... unused
- Starting Listener...su: error while loading shared libraries: libcrypt.so.1: wrong ELF class: ELFCLASS32
failed

+ Starting Database(s)...su: error while loading shared libraries: libcrypt.so.1: wrong ELF class: ELFCLASS32
cat: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32
su: error while loading shared libraries: libcrypt.so.1: wrong ELF class: ELFCLASS32
Status of Oracle database(s) start: failed

- Starting Apache... unused
- Starting Agent... unused
- Starting Connection Manager... unused
- Starting Oracle Internet Filesystem... unused
- Starting Oracle Internet Directory... unused

#############################################################################
# End of O R A C L E section #
#############################################################################

[/quote]


The main problem is this:

[quote]
cat: error while loading shared libraries: libc.so.6: wrong ELF class: ELFCLASS32
[/quote]

I tried a lot with this settings, to use the old librarys:

[quote]
export LD_LIBRARY_PATH=/opt/ora10g/lib/stubs:/opt/ora10g/lib
[/quote]

This glibc packetes are installed:

[quote]
compat-glibc.i386 1:2.3.4-2.26 installed
compat-glibc-headers.x86_64 1:2.3.4-2.26 installed
glibc.i686 2.5-49 installed
glibc.x86_64 2.5-49 installed
glibc-common.x86_64 2.5-49 installed
glibc-devel.i386 2.5-49 installed
glibc-devel.x86_64 2.5-49 installed
glibc-headers.x86_64 2.5-49 installed
compat-glibc.x86_64 1:2.3.4-2.26 base
glibc-utils.x86_64 2.5-49 base
[/quote]

I think the problem is the Version 2.5 of glibc, but oracle should use the libs from /opt/ora10g/lib/stubs and /opt/ora10g/lib.

What is the problem?

Best regards,

d3javu

[d3javu]

No ideas?
Time is running out ... :(

[rger]

Hi d3javu,

i don't have a solution to your problem, only a few thoughts you might check if not already done:

- your CentOS 5.x is 64bit (uname -a)
- all installed oracle is 64bit as well


I've a working installation of 10g (10.2.0.4) on CentOS 5.2 for about 2 years. The setting
of LD_LIBRARY_PATH wasn't necessary, I edited "/etc/security/limits.conf" and "/etc/sysctl.conf"


[.....]
# minimum requirement for Oracle DB (see note 421308.1 in metalink)
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144


Regards,

Ralf