RMAN duplicate target database for standby from active fails to create newname for system tablespace/datafile

Question

When executing 'duplicate target database for standby from active'  the system tablespace/datafile (datafile 1)  is not cloned.  All other datafiles clone successfully.  The RMAN process aborts with the following errors while attempting to clone the system tablespace/datafile.
ORA-19558: error de-allocating device
ORA-19557: device error, device type: DISK, device name:
ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
ORA-17627: ORA-01041: internal error. hostdef extension doesn't exist
ORA-03135: connection lost contact
Here are the details:
Primary is 11.2.0.2 RAC database  on an Exadata platform
Standby is 11.2.0.2 Single Instance database (same patch level as primary) on a Red Hat Linux box
This is an ASM to ASM duplication.
This is not unique to this database.  We tried another database and go the same behavior - all datafiles clone successfully with the exception of the system tablespace/datafile.
We have traced the RMAN execution and it seems to fail when it is trying to assign a NEWNAME to the system tablespace/datafile.
We even issued an explicit SET NEWNAME command but RMAN ignored it.
We also shutdown the primary and started is up in mount mode thinking that something had ahold of the System Tablespace/datafile.
We also opened up the network firewall to allow permit any,any traffic.
We increased the max_server_processes
and added TCP.NODELAY=yes to the sqlnet.ora file.
There seems to be some artifact present in our Primary System tablespace/data file that is preventing it form being cloned.
checked all alert files grid, asm,  and dbhome - no abnormal messages.
We are in the process of restoring the database from a backup but we would prefer to get this working using the 'Active Database' methodology

Answer 1

I successfully created the standby database using RMAN backup and recovery.
I started the managed recovery.  Archive logs are being sent from the primary to the standby ( I can see them in ASM), but the standby is not applying them.
I get the following messages in the standby alert log...
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:19:58 2013
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Tue Nov 26 16:20:01 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:11 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:22 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
Tue Nov 26 16:20:32 2013
Fetching gap sequence in thread 2, gap sequence 154158-154257
I don't see any MRP processes:
select process,
status,
    thread#,
    sequence#,
   block#,
  blocks
  7     from v$managed_standby;
PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
ARCH      CLOSING               2     154363          1        132
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
RFS       IDLE                  0          0          0          0
RFS       IDLE                  1     145418        121          1
RFS       IDLE                  0          0          0          0
PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
RFS       IDLE                  0          0          0          0
12 rows selected.
SQL>  SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
   THREAD#  SEQUENCE# APPLIED
         2     154356 NO
         2     154357 NO
         1     145411 NO
         2     154358 NO
         2     154360 NO
         2     154361 NO
         1     145414 NO
         1     145415 NO
         2     154362 NO
         2     154363 NO
         1     145416 NO
11 rows selected.
I do have the archive logs that cover sequences 154158-154257
Crosschecked 38 objects
Crosschecked 62 objects
Finished implicit crosscheck backup at 26-NOV-13
Starting implicit crosscheck copy at 26-NOV-13
using channel ORA_DISK_1
using channel ORA_DISK_2
Crosschecked 2 objects
archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154377.344.832521989 RECID=29 STAMP=832521990
validation succeeded for archived log
archived log file name=+RECO_XORA/nmuasb00/archivelog/2013_11_26/thread_2_seq_154378.346.832521991 RECID=31 STAMP=832521993
Crosschecked 31 objects