在linux 5上装10G RAC时，常常会碰到“libpthread.so.0: cannot open shared object file"这个报错的，这个报错是由于无法使用vipca导致的。该报错有以下两种解决方案：
方法1
不去理会，选择继续，然后安装10.2.0.4及以上版本的patchsets，然后在来手工执行vipca完成vip配置工作，因为这个错误在10.2.0.4版本中已经得到修复
方法2
In this Document
Symptoms
Cause
Solution
References
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 - Release: 10.2 to 10.2
Linux x86
Generic Linux
Linux x86-64
***Checked for relevance on 04-Aug-2010***
When installing 10gR2 RAC on Oracle Enterprise Linux 5 or RHEL5 or SLES10 there are three issues that users must be aware of.
Issue#1: To install 10gR2, you must first install the base release, which is 10.2.0.1. As these version of OS are newer, you should use the following command to invoke the installer:
$ runInstaller -ignoreSysPrereqs // This will bypass the OS check //
Issue#2: At end of root.sh on the last node vipca will fail to run with the following error:
Oracle CRS stack installed and running under init(1M) Running vipca(silent) for configuring nodeapps /home/oracle/crs/oracle/product/10/crs/jdk/jre//bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
Also, srvctl will show similar output if workaround below is not implemented.
Issue#3: After working around Issue#2 above, vipca will fail to run with the following error if the VIP IP's are in a non-routable range [10.x.x.x, 172.(16-31).x.x or 192.168.x.x]:
# vipca Error 0(Native: listNetInterfaces:[3]) [Error 0(Native: listNetInterfaces:[3])]
These releases of the Linux kernel fix an old bug in the Linux threading that Oracle worked around using LD_ASSUME_KERNEL settings in both vipca and srvctl, this workaround is no longer valid on OEL5 or RHEL5 or SLES10 hence the failures.
If you have not yet run root.sh on the last node, implement workaround for issue#2 below and run root.sh (you may skip running the vipca portion at the bottom of this note).
If you have a non-routable IP range for VIPs you will also need workaround for issue# 3 and then run vipca manually.
To workaround Issue#2 above, edit vipca (in the CRS bin directory on all nodes) to undo the setting of LD_ASSUME_KERNEL. After the IF statement around line 120 add an unset command to ensure LD_ASSUME_KERNEL is not set as follows:
if [ "$arch" = "i686" -o "$arch" = "ia64" -o "$arch" = "x86_64" ] then LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL fi
unset LD_ASSUME_KERNEL <<<== Line to be added
Similarly for srvctl (in both the CRS and, when installed, RDBMS and ASM bin directories on all nodes ), unset LD_ASSUME_KERNEL by adding one line, around line 168 should look like this:
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
unset LD_ASSUME_KERNEL <<<== Line to be added
Remember to re-edit these files on all nodes:
after applying the 10.2.0.2 or 10.2.0.3 patchsets, as these patchset will still include those settings unnecessary for OEL5 or RHEL5 or SLES10. This issue was raised with development and is fixed in the 10.2.0.4 patchsets.
Note that we are explicitly unsetting LD_ASSUME_KERNEL and not merely commenting out its setting to handle a case where the user has it set in their environment (login shell).
To workaround issue#3 (vipca failing on non-routable VIP IP ranges, manually or during root.sh), if you still have the OUI window open, click OK and it will create the "oifcfg" information, then cluvfy will fail due to vipca not completed successfully, skip below in this note and run vipca manually then return to the installer and cluvfy will succeed.