When I hit this problem I did some searching and found the same solutions, but none with the trick that I needed. While they present how to solve the problem, the trick in my case was in how the problem was actually created.
When I installed the 11.2 Grid Infrastructure it failed on node 2 because the disks hadn’t been named correctly. On each node the device names pointed to different disks. So node 1 installed fine, but when it got to node 2 the install failed because it couldn’t mount the OCRVOTE diskgroup because it had the wrong disks assigned. I got the /etc/multipath and udev rules corrected and all the disks mounted correctly, and then tried to reinstall the Grid Infrastructure.
On the re-install, when I came to the diskgroup configuration, I entered OCRVOTE as the diskgroup name and select the five disks that were designated for it. I then got:
[INS-30516] - Please specify unique disk groups. Cause - Installer has detected that the diskgroup name provided already exists on the system. Action - Specify different diskgroup.
The solution for this, as you’ll find on other sites, is to “clear the disk”. How you do this depends on whether you use the Oracle ASM utilities or not. If you use Oracle ASM utilities (oracleasm) then you can do “oracleasm deletedisk …” and then an “oracleasm createdisk …”. You could probably use dd also, but to be safe the deletedisk and createdisk is probably safest.
I’m not using oracleasm, just disks (storage LUNs) with multipath and udev to name and set permissions. The solution for that is to simply clear the disk out with something like:
dd if=/dev/zero of=/dev/mapper/ORA_5G_03p1 bs=1024k count=50
So, I did that to all five of the disks. I restarted runInstaller and ran into the same error. I then went though a series of slightly different variations of the dd, including leaving count off to ensure the whole disk was wiped, but to no avail.
I searched for any files that oracle might have left on the server and cleaned those up. Still no luck. I then decided to try using OCRVOTE1 as the diskgroup name and Oracle was happy, but wanting to understand, not just work around the problem I didn’t proceed with the install.
Literally, as I was walking out of the office it hit me, and I went back to my desk. The device names had been pointing at the wrong disks when I first built it. Maybe Oracle runInstaller was looking at all of the candidate disks and finding the name OCRVOTE on one of the other candidate disks that had previously been mounted as my OCRVOTE disks! You’d think it would only examine disks in use, but hey, it was worth checking.
So, I used a trick Matt M showed me – just pipe your dd to hexdump to see if something is there. The first five of my 200G disks showed something other than zero, but after that they did show empty.
Here is one of the first disks partitions (one that had incorrectly been named as OCRVOTE disk), you can see that it has data written it:
# dd if=/dev/mapper/ORA_200G_04p1 bs=1024 count=10 | hexdump 0000000 8201 0101 0000 0000 0000 8000 65c7 75d1 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 524f 4c43 4944 4b53 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 0000040 0000 0b20 0000 0303 434f 5652 544f 5f45 0000050 3030 3030 0000 0000 0000 0000 0000 0000 0000060 0000 0000 0000 0000 434f 5652 544f 0045 0000070 0000 0000 0000 0000 0000 0000 0000 0000 0000080 0000 0000 0000 0000 434f 5652 544f 5f45 0000090 3030 3030 0000 0000 0000 0000 0000 0000 ... continues ...
Here is the 6th 200G disk that was not originally used and, as you can see, it is just zeroes:
# dd if=/dev/mapper/ORA_200G_05p1 bs=1024 count=10 | hexdump 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0002800 10+0 records in 10+0 records out 10240 bytes (10 kB) copied, 0.00185966 s, 5.5 MB/s
So, for good measure I ran dd on all of the other “candidate” disks to wipe them clean, then restarted runInstaller and everything worked just fine.
The trick was not that the disks I was selecting for the diskgroup had a problem, but that other “Candidate” disks had the name OCRVOTE in their headers. If you decide to wipe a RAC install and create a new one you would probably run into the same problem (though in that case you’d hopefully wipe all the disks first).