Error "ORA-01882 timezone region not found" when creating new domain in Oracle® WebLogic

The problem

During domain configuration I received an error saying ORA-01882 timezone region not found when I clicked on the Get RCU Configuration button.

The cause

This is because your operating system is either using a invalid timezone value, or using the Etc/UTC or Universal timezone. The two latter examples are due to a bug when connecting to the database. 

The solution

1. Exit the domain configuration assistant
2. Set a timezone value accepted by the database: TZ=UTC; export TZ
3. Start the domain configuration assistant again by running config.sh
4. To prevent the same issue from happening again (assuming you hit the bug), you should add the corrected TZ to the software owner's profile, e.g. in $HOME/.bash_profile if you are using the Bourne Again Shell. However, if your Linux server clock is configured with an invalid timezone, you should fix it at Linux level by using a IANA compliant timezone.

OPatch failed with error code 73

The problem

I came across a sandbox server which had an interesting problem with oraInventory. When running opatch I received the following error:

Inventory load failed... OPatch cannot load inventory for the given Oracle Home.

Possible causes are:

   Oracle Home dir. path does not exist in Central Inventory

   Oracle Home is a symbolic link

   Oracle Home inventory is corrupted

LsInventorySession failed: Oracle Home inventory cannot be loaded.

OPatch failed with error code 73

The cause

The immediate cause was that /u01/app/oraInventory was empty besides the "locks" directory that got created when I ran $ORACLE_HOME/OPatch/opatch lsinventory.

/etc/oraInst.loc pointed to the /u01/app/oraInventory directroy, and so did $ORACLE_HOME/oraInst.loc.

I looked for other copies of oraInventory on the server, but there were none.

I can only speculate on why /u01/app/oraInventory was empty. Perhaps someone deleted the contents by mistake, or by some misguided effort to free up disk space.

The solution

Had this been a production system it would have made sense to check the file system backup, and do a restore of /u01/app/oraInventory. But his was just a sandbox, and no file system backup existed. 

The solution was to run $ORACLE_HOME/oui/bin/attachHome.sh to populate the oraInventory again. 

Now the command $ORACLE_HOME/OPatch/opatch lsinventory worked fine.

Server subsystem failed. Reason: A MultiException has 10 exceptions when starting Oracle® WebLogic managed server

The problem

After starting the Oracle® WebLogic AdminServer in a sandbox environment, I attempted to start the managed servers, but got the following errors in the $DOMAIN_HOME/servers/<ms-server>/logs/<ms-server>.out log file:

<Feb 5, 2016 8:31:03 AM UTC> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: A MultiException has 10 exceptions.  They are:

1. java.lang.AssertionError: Assertion violated

2. java.lang.IllegalStateException: Unable to perform operation: post construct on weblogic.ldap.EmbeddedLDAP

3. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.security.PreSecurityService errors were found

4. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.security.PreSecurityService

5. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.security.SecurityService errors were found

6. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.security.SecurityService

7. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.jndi.internal.RemoteNamingService errors were found

8. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.jndi.internal.RemoteNamingService

9. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.jndi.internal.ForeignJNDIManagerService errors were found

10. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.jndi.internal.ForeignJNDIManagerService

A MultiException has 10 exceptions.  They are:

1. java.lang.AssertionError: Assertion violated

2. java.lang.IllegalStateException: Unable to perform operation: post construct on weblogic.ldap.EmbeddedLDAP

3. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.security.PreSecurityService errors were found

4. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.security.PreSecurityService

5. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.security.SecurityService errors were found

6. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.security.SecurityService

7. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.jndi.internal.RemoteNamingService errors were found

8. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.jndi.internal.RemoteNamingService

9. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.jndi.internal.ForeignJNDIManagerService errors were found

10. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.jndi.internal.ForeignJNDIManagerService

        at org.jvnet.hk2.internal.Collector.throwIfErrors(Collector.java:88)

        at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:269)

        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)

        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)

        at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)

        Truncated. see log file for complete stacktrace

Caused By: java.lang.AssertionError: Assertion violated

        at weblogic.utils.Debug.assertion(Debug.java:58)

        at weblogic.server.channels.ChannelService.getServerChannel(ChannelService.java:2049)

        at weblogic.server.channels.ChannelService.getServerChannel(ChannelService.java:1987)

        at weblogic.protocol.ServerChannelManager.findServerChannel(ServerChannelManager.java:79)

        at weblogic.ldap.EmbeddedLDAP.findLdapURL(EmbeddedLDAP.java:1082)

        Truncated. see log file for complete stacktrace

>

The solution

This turned out to be a side effect of a mismatch between the domain binaries and the domain version number in $DOMAIN_HOME/config/config.xml. I have written about that here: http://audunnes.blogspot.dk/2016/02/the-domain-version-122100-is-greater.html

The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server when starting an Oracle® WebLogic managed server.

The problem

After starting the Oracle® WebLogic AdminServer in a sandbox environment, I attempted to start the managed servers, but got the following errors in the $DOMAIN_HOME/servers/<ms-server>/logs/<ms-server>.out log file:

<Error> <Configuration Management> <BEA-150001> <An error occurred while connecting to the Administration Server to bootstrap through the URL: http://localhost:7001/bea_wls_management_internal2/Bootstrap,

 user: weblogic.

weblogic.management.configuration.ConfigurationException: [Management:141252]The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server.

        at weblogic.management.provider.internal.BootStrapHelper.getBootStrapStruct(BootStrapHelper.java:147)

        at weblogic.management.provider.internal.RuntimeAccessImpl.initialize(RuntimeAccessImpl.java:444)

        at weblogic.management.provider.internal.RuntimeAccessService.start(RuntimeAccessService.java:70)

        at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:606)

        at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)

        at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)

        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)

        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)

        at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)

        at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)

        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)

        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)

        at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)

        at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)

        at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)

        at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)

        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)

        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)

        at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)

        at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)

        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)

        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)

        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)

        at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)

        at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)

The cause

I was at first a bit puzzled by the message "The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server." because the AdminServer console footer said it was version 12.1.3.0, and the startup scripts in $DOMAIN_HOME/bin also only pointed to 12.1.3.0 binaries.

I discovered there were 12.2.1.0.0 binaries installed in a new $ORACLE_HOME, but as mentioned, these binaries were not referenced by the scripts in $DOMAIN_HOME/bin.

The fact that 12.2.1.0.0 binaries were available on the file system suggested someone had either planned to create a new 12.2.1.0.0 domain, or planned to upgrade the existing 12.1.3.0 domain.

After discussing this with a colleague it became clear that he had installed the new binaries, and that all he wanted to do with them was to create response files for running the upgrade of a domain on a different server. He only intended to run the information collection part, but it had obviously also touched the $DOMAIN_HOME/config/confix.xml file in the 12.1.3.0 domain, and changed the version parameter to 12.2.1.0.0 as shown below:

$ grep version $DOMAIN_HOME/config/config.xml
<?xml version='1.0' encoding='UTF-8'?>
  <domain-version>12.2.1.0.0</domain-version>
  <configuration-version>12.2.1.0.0</configuration-version>

The solution

1. Shutdown the entire domain. In my case that meant the AdminServer and the NodeManager.
2. Took a file system backup of $DOMAIN_HOME
3. Edited $DOMAIN_HOME/config/config.xml and replaced the two occurences of 12.2.1.0.0 with 12.1.3.0.0
4. Started the NodeManager, the AdminServer and the managed servers up without any errors.

Post-change verification:

$ grep version config.xml

<?xml version='1.0' encoding='UTF-8'?>

  <domain-version>12.1.3.0.0</domain-version>

  <configuration-version>12.1.3.0.0</configuration-version>

Unexpected EOF in prolog when starting Oracle® WebLogic AdminServer

The problem

The Oracle® WebLogic AdminServer has started up and reached RUNNING state, but I have the habit of checking the AdminServer.out file after startup, and today I saw the following error:

<Error> <Default> <J2EE JMX-47001> <A JAXB error occurred during unmarshalling of "usermessagingconfig.xml".

javax.xml.bind.UnmarshalException

 - with linked exception:

[Exception [EclipseLink-25004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.XMLMarshalException

Exception Description: An error occurred unmarshalling the document

Internal Exception: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog

 at [row,col {unknown-source}]: [1,0]]

        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.handleXMLMarshalException(JAXBUnmarshaller.java:980)

        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:588)

        at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:140)

        at oracle.as.config.persistence.jaxb.JAXBXmlPersistenceManagerImpl.load(JAXBXmlPersistenceManagerImpl.java:190)

        at oracle.as.jmx.framework.util.DefaultConfigObjectMBeanAssociationInfo.loadConfigObject(DefaultConfigObjectMBeanAssociationInfo.java:638)

        at oracle.as.jmx.framework.util.DefaultConfigObjectMBeanAssociationInfo.initializeConfigObjectAndAssociatedMBean(DefaultConfigObjectMBeanAssociationInfo.java:676)

        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerMBeans(ComponentMBeans.java:244)

        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerDomainLevelMBeans(ComponentMBeans.java:356)

        at oracle.as.jmx.framework.wls.spi.ComponentMBeans.registerRuntimeMBeanServerMBeans(ComponentMBeans.java:373)

        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl$3.run(JMXFrameworkProviderImpl.java:1134)

        at java.security.AccessController.doPrivileged(Native Method)

        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl.initRuntimeMBeanServer(JMXFrameworkProviderImpl.java:1127)

        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl.access$200(JMXFrameworkProviderImpl.java:210)

        at oracle.as.jmx.framework.wls.spi.JMXFrameworkProviderImpl$2.run(JMXFrameworkProviderImpl.java:1080)

        at java.lang.Thread.run(Thread.java:745)

Caused By: Exception [EclipseLink-25004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.XMLMarshalException

The cause

The usermessagingconfig.xml in question was located in $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml

ls -l $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml confirmed that the file had not been update since the 9th of September 2015, but then again this WebLogic server had been running for several months before I restarted it today. This is a sandbox server so it is used very infrequently.

ls -l $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml also showed me that the size was 0 bytes. 

I remembered that the mount point where WebLogic stores its domain configuration files ran out of disk space in September last year. At that time it corrupted the EmbeddedLDAP folder, but after clearing the log files and re-creating the EmbeddedLDAP, WebLogic was started up again. In hindsight I realize that the same error with usermessagingconfig.xml must have been in AdminServer.out back then as well, but I obviously failed to notice it at the time. 

The solution

I added the following to $DOMAIN_HOME/config/fmwconfig/usermessagingconfig.xml:

<?xml version="1.0"?>

<MessagingConfiguration xmlns="http://www.oracle.com/ucs/messaging/config"

                        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                        xsi:schemaLocation="http://www.oracle.com/ucs/messaging/config ../config.xsd" version="12.1.3.0.0">

  <Server>

  </Server>

</MessagingConfiguration>

Then restarted the AdminServer, and the error was gone.

Oracle® 12c Database Configuration Assistant hangs on Oracle® Linux 7 in VirtualBox 5

I recently installed Oracle® Linux 7.2 on my VirtualBox 5.0.14 installation on Windows 7 in order to have a private playground for evaluating software. Afterwards I installed Oracle® 12c database version 12.1.0.2 on my new virtual Linux server. This went fine until I fired up Database Configuration Assistant (DBCA) in order to create a playground database. DBCA just hanged forever without consuming noticeable CPU. I kept it running for an entire night, but it never started fully up. It kept hanging at the splash screen as shown below:

Investigations

The log file $ORACLE_BASE/cfgtoollogs/dbca/trace.log_OraDB12Home1_<timestamp> showed the following:

[main] [ 2016-02-04 10:06:33.737 CET ] [Host.<init>:1090]  Begin tracing..

[main] [ 2016-02-04 10:06:34.971 CET ] [UIHost.createHelpSet:485]  HelpSetParseExceptionjava.lang.NullPointerException

[main] [ 2016-02-04 10:06:36.703 CET ] [Host.checkIfBigClusterAndHubNode:1710]  Not a cluster environment: exiting BigCluster Check

[main] [ 2016-02-04 10:06:36.708 CET ] [InventoryUtil.getOUIInvSession:349]  setting OUI READ level to ACCESSLEVEL_READ_LOCKLESS

[main] [ 2016-02-04 10:06:36.708 CET ] [InventoryUtil.isCRSHome:386]  Homeinfo /u01/app/oracle/product/12.1.0/dbhome_1,1

[main] [ 2016-02-04 10:06:36.922 CET ] [Host.validateGridHome:3878]  Validation false

[main] [ 2016-02-04 10:06:36.922 CET ] [Host.startOperation:2395]  Source db null

[main] [ 2016-02-04 10:06:36.922 CET ] [Host.startOperation:2396]  GDB Name null

[main] [ 2016-02-04 10:06:36.957 CET ] [Host.startOperation:2397]  MgmtDB sid -MGMTDB

[main] [ 2016-02-04 10:06:36.957 CET ] [Host.startOperation:2398]  MgmtDB name _mgmtdb

[main] [ 2016-02-04 10:06:36.998 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: null

[main] [ 2016-02-04 10:06:37.000 CET ] [InventoryUtil.getOUIInvSession:349]  setting OUI READ level to ACCESSLEVEL_READ_LOCKLESS

[main] [ 2016-02-04 10:06:37.000 CET ] [OracleHome.getVersion:1010]  Homeinfo /u01/app/oracle/product/12.1.0/dbhome_1,1

[main] [ 2016-02-04 10:06:37.181 CET ] [OracleHome.getVersion:1038]  OracleHome.server.getVersion Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.182 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.182 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.182 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.183 CET ] [CommonUtils.createPasswordFile:1243]  calling new orapwd for 11.1 or higher

[main] [ 2016-02-04 10:06:37.183 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.184 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.184 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.184 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.184 CET ] [CommonUtils.getPasswordFileCreateCmd:1182]  for new orapwd for 11.1 or higher

[main] [ 2016-02-04 10:06:37.189 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.190 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.190 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.190 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.191 CET ] [CommonUtils.getPasswordFileCreateCmd:1213]  /u01/app/oracle/product/12.1.0/dbhome_1/bin/orapwd

[main] [ 2016-02-04 10:06:37.191 CET ] [CommonUtils.getPasswordFileCreateCmd:1213]  file=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/orapwDBUA0636958

[main] [ 2016-02-04 10:06:37.191 CET ] [CommonUtils.getPasswordFileCreateCmd:1213]  force=y

[main] [ 2016-02-04 10:06:37.191 CET ] [CommonUtils.getPasswordFileCreateCmd:1213]  format=12

[main] [ 2016-02-04 10:06:37.192 CET ] [OsUtilsBase.execProg:2123]  beginning execProg with input array.

[main] [ 2016-02-04 10:06:37.377 CET ] [OsUtilsBase.execProg:2160]  finished execProg with input array. Status:0

[main] [ 2016-02-04 10:06:37.378 CET ] [OracleHome.initOptionsStopOnError:1356]  Initializing Database Options with  for dummy sid=DBUA0636958 using initfile=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/initDBUA0636958.ora using pwdfile=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/orapwDBUA0636958

[main] [ 2016-02-04 10:06:37.398 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.399 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.399 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.400 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.400 CET ] [OracleHome.getVersion:991]  OracleHome.getVersion called.  Current Version: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.401 CET ] [OracleHome.getVersion:1059]  Current Version From Inventory: 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.402 CET ] [SQLPlusEngine.getCmmdParams:225]  m_home 12.1.0.2.0

[main] [ 2016-02-04 10:06:37.402 CET ] [SQLPlusEngine.getCmmdParams:226]  version > 112 true

[main] [ 2016-02-04 10:06:37.403 CET ] [SQLEngine.getEnvParams:612]  NLS_LANG: AMERICAN_AMERICA.AL32UTF8

[main] [ 2016-02-04 10:06:37.421 CET ] [SQLEngine.initialize:358]  Execing SQLPLUS/SVRMGR process...

[main] [ 2016-02-04 10:06:37.467 CET ] [SQLEngine.initialize:395]  m_bReaderStarted: false

[main] [ 2016-02-04 10:06:37.467 CET ] [SQLEngine.initialize:399]  Starting Reader Thread...

[main] [ 2016-02-04 10:06:42.068 CET ] [OracleHome.initOptionsStopOnError:1370]  executing: startup nomount pfile='/u01/app/oracle/product/12.1.0/dbhome_1/dbs/initDBUA0636958.ora'

The 'ps -ef' command also confirms that sqlplus is stuck in "startup nomount"

Some unsuccessful attempts

- Tried with CentOS 7.1 instead of Oracle® Linux 7.2. Replicated the issue 100%.

- Tried to run DBCA as part of the Oracle® 12c Database installation (Software and starter database) and after a software only install. Same problem in both cases. 

Searching for an answer

I found a similar issue described in https://community.oracle.com/message/13249304#13249304, but no solution was offered, 

The solution

After various unsuccessful attempts to fix this at Linux level, I turned my attention to VirtualBox. After trying to tweak several options, I found the culprit to be the Paravirtualization Interface for acceleration. Changing that from Default to None fixed the issue.

I did not try all the various options for Paravirtualization Interface, but in my setup both with Default and Legacy I faced issues with DBCA.