Back on August 22, 2015, I wrote a post about some challenges I was experiencing while trying to install Oracle DB12c on Linux 7 using VirtualBox 5.x. You can read that here. Since then, I have had the opportunity to work with Simon Coter, Principal Product Manager for Oracle VM and VirtualBox to get to the root of this problem. In particular the segmentation fault when you run the root.sh script.

Environment:

Oracle Virtual Box 5.0.12
MacBook Pro (Retina, 15-inch, Mid 2014)
Processor: 2.2 GHz Intel Core i7

Take a look at the following image and snippet from the installation log file:

Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/12.1.0/grid
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
/u01/app/oracle/product/12.1.0/grid/crs/config/rootconfig.sh: line 131:  2949 Segmentation fault      (core dumped) $ROOTSCRIPT $ROOTSCRIPT_ARGS
The command '/u01/app/oracle/product/12.1.0/grid/perl/bin/perl -I/u01/app/oracle/product/12.1.0/grid/perl/lib -I/u01/app/oracle/product/12.1.0/grid/crs/install /u01/app/oracle/product/12.1.0/grid/crs/install/roothas.pl  -auto -lang=en_US.UTF-8' execution failed

As you can see, this is related to Perl and the initial solution proposed was to recompile the Perl binaries then your installation would complete.

What is really going on here?  According to my friends on the Virtual Box team:
“It appears that there maybe a bug in the intel-compiler that is not able to leverage 4th cache-level available on some modern CPUs. Very recent Intel CPUs have 4 cache descriptors and VBox 5.0.x passes this information to the guest. For those of you that  are still running VBox 4.3.x, “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.”

In order to correct this issue, you must execute the following series of commands PRIOR to running your VM where <VM name> is the name of the VBox VM.

These 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"

If you need to figure out the VM name, you can execute VBoxManage list vms at your command prompt.

Note, this fix is on a per virtual machine basis. I will continue to work with Oracle and hopefully we will see a more permanent solution.

Enjoy!