Oracle 12.1.0.2 Grid Installation fails to relink VB5 on Oracle Linux 6.7 guest,OSX host

[MPMDBA]

When trying to install 12.1.0.2 Grid Infrastructure on Linux 6.7 guest on OS X (Yosemite) host using VirtualBox 5 the installer hangs at 59% (after passing all the Oracle pre-requisites) with the error

error invoking target irman ioracle of makefile /u01/app/gi/12.1.0.2/grid/rdbms/lib/ins_rdbms.mk”
The logs provide further detail.

INFO: /usr/bin/ld: cannot find -ljavavm12
collect2: ld returned 1 exit status

INFO: make: *** [/u01/app/gi/12.1.0.2/grid/rdbms/lib/oracle] Error 1

It is possible to work around this by copying the libjavavm12.a library located in $ORACLE_HOME/javavm/jdk/jdk7/lib to $ORACLE_HOME/lib directory and retrying the install.

Once the workaround is applied, the installer continues but then the oracle root.sh script fails with a segmentation fault.

rootconfig.sh: line 131: 4562 Segmentation fault

A workaround can be applied by reinstalling the Perl binaries under the newly created ORACLE_HOME and the installation can continue.

Both errors and their work arounds are described here:  http://laurent-leturgez.com/2015/05/26/oracle-12c-vmware-fusion-and-the-perl-binarys-segmentation-fault/#comment-7644

Note, this is not my blog but has been very helpful in providing the 2 workarounds for the issue I report here. It would be great if a permanent fix could be found is it seems this is something specific to Virtual Box 5 rather than an issue with the guest config.

[frank]

Still relevant with VBox 5.0.2? In that case, please attach a VBox.log file of a 5.0.2 session.

[MPMDBA]

This error still occurs in 5.0.2 even after rebuilding the guest from scratch and correctly installing the guest additions. Attached the VBox.log file.

[frank]

Please check what happens if you do

VBoxManage setextradata VM_NAME VBoxInternal/CPUM/IsaExts/AVX 0

before you start your VM.

[piter75]

The problem with Oracle's perl crashing because of segmentation fault still exists in 5.0.10.

It happens regardless of "VBoxInternal/CPUM/IsaExts/AVX" extradata settings.

[Lelik]

I'm trying to reproduce perl crash. Installed "Oracle Grid Infrastructure Software Only" option.

cd /vbox/app/oracle/product/12.1.0/grid/perl/bin './perl -v' no cash, perl 15.14.1

root.sh script also doesn't crash.

Is it possible to reproduce it with this software configuration, or I should do something else?

My CPU is similar to attached VBox.log: Matched host CPU INTEL 0x6/0x3d/0x4 Intel_Core7_Broadwell with CPU DB entry 'Intel Core i5-3570' (INTEL 0x6/0x3a/0x9 Intel_Core7_IvyBridge)

[frank]

It turns out that this is a bug in the perl binary. It links against ancient code from the Intel compiler suite doing optimizations according to the CPU features. Very recent Intel CPUs have 4 cache descriptors and VBox 5.0.x passes this information to the guest. This leads to a problem within the perl code. The following commands tweak the CPUID bits passed to the guest:

VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/Leaf"        "0x4"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/SubLeaf"     "0x4"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/eax"         "0"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/ebx"         "0"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/ecx"         "0"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/edx"         "0"
VBoxManage setextradata VM_NAME "VBoxInternal/CPUM/HostCPUID/Cache/SubLeafMask" "0xffffffff"

Replace VM_NAME by the name of your VM.

This problem was not triggered on VBox 4.3.x because this version did not pass the full CPUID cache line information to the guest.