Opatch java.lang.UnsatisfiedLinkError: no oraInstaller in java.library.path wrong ELF class: ELFCLASS64

I got this error when trying to deploy an interim patch for soa installation using opatch on Solaris.




Opatch java.lang.UnsatisfiedLinkError: no oraInstaller in java.library.path wrong ELF class: ELFCLASS64


oracle@xxxxxxx:[/u01/app/oracle/product/11.1.1.5/ofm1/fms/soa/patch_top/13683187]# opatch apply

The above error indicates that the opatch has encountered a 64 bit library while it was expecting a 32 bit, that means opatch was started as a 32 bit jvm. The java installation in the solaris box had both 32 bit and 64 bit jvms. So by default OPatch was starting as a 32 bit jvm , while the soa installation/ora installer on the ORACLE_HOME was 64 bits. The fix for this is to update the opatch script to add the “-d64″ flag so that opatch starts as a 64 bit jvm.




$JAVA -d64 $JAVA_VM_OPTION $JRE_MEMORY_OPTIONS -cp $BASE/ocm/lib/emocmutl.jar:$BASE/ocm/lib/emocmclnt.jar:$CP/OraInstaller.jar:$CP/OraPrereq.jar:$CP/share.jar:$CP/srvm.jar:$CP/orai18n-mapping.jar:$CP/xmlparserv2.jar:$BASE/jlib/opatch.jar:$BASE/jlib/opatchutil.jar:$BASE/jlib/opatchprereq.jar:$BASE/jlib/opatchactions.jar:$BASE/jlib/opatchext.jar:$BASE/jlib/opatchfmw.jar:$WEBLOGIC_CLASSPATH -DOPatch.ORACLE_HOME=$OH -DOPatch.DEBUG=$DEBUGVAL -DOPatch.RUNNING_DIR=$BASE -DOPatch.MW_HOME=$MWH -DOPatch.WL_HOME=$WL_HOME -DOPatch.COMMON_COMPONENTS_HOME=$COMMON_COMPONENTS_HOME ${oracleOcmService} ${_bootClassPath} oracle/opatch/OPatch $@      

One more possible cause of Unsatisfied linked error in linux is incorrect LD_LIBRARY_PATH, if .so files are not there you may get this error. see http://javarevisited.blogspot.sg/2012/03/javalangunsatisfiedlinkerror-no-dll-in.html for more details

This host is VT-capable, but VT is disabled

While starting VM on 64 bit, got following error -

This virtual machine is configured for 64-bit guest operating systems. However, 64-bit operation is not possible.

This host is VT-capable, but VT is disabled.

VT might be disabled if it has been disabled in the BIOS settings or the host has not been power-cycled since changing this setting.

(1) Verify that the BIOS settings enable VT and disable 'trusted execution.'

(2) Power-cycle the host if either of these BIOS settings have been changed.

(3) Power-cycle the host if you have not done so since installing VMware Player.

(4) Update the host's BIOS to the latest version.

For more detailed information, see http://vmware.com/info?id=152.

Continue without 64-bit support?

Resoulution -

We are still trying to determine what causes this problem on some systems.  In the meantime, as a workaround, please add the following line to C:\ProgramData\VMware\VMware Workstation\config.ini:

hv.assumeEnabled = TRUE

Note that ProgramData is a hidden folder.

new error - 

*** VMware Player internal monitor error ***

vcpu-0:VT is disabled and locked on this CPU.

Solution -


Go to BIOS setup- 
- Restore CMOS factory default setting
- Make sure to enable Virtulization Technology
- Cold boot the system

Issue solved ... :)