by Brian Fitzgerald

Introduction

This article covers “Successful discovery of 0 disks” errors during grid launch. I know of three fixes.

System

Installing Oracle Clusterware 19c on top of ASMLIB 3.0 on Red Hat Linux.

Installation notes

In this article, the grid owner is oracle, group dba. The ASM disks are named ORA_ASM_GRID1_01, and so on, and you can refer to them that way:

/dev/disk/by-label/ORA_ASM_GRID1_01

and so on.

The error

After running gridSetup.sh as the grid owner, the DBA runs root.sh. On the first node, the error happens in step 16 of 19: ‘InitConfig’. On the second node, the failure appears at step 17 of 19: ‘StartCluster’. root.sh runs for 10 minutes and fails.

The root.sh refers to a log such as $ORACLE_HOME/install/root_$(hostname)$(date…).log, which begins:

Performing root user operation.

On the first node, the error is:

[FATAL] [DBT-30002] Disk group GRID1 creation failed.
ORA-15018: diskgroup cannot be created
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_01' matches no disks
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_02' matches no disks
ORA-15031: disk specification 'ORCL:ORA_ASM_GRID1_03' matches no disks

And on the second, you will find:

CRS-1705: Found 0 configured voting files but 1 voting files are required, terminating to ensure data integrity; details at (:CSSNM00065:) in /u01/app/oracle/diag/crs/<hostname>/crs/trace/ocssd.trc
CRS-2883: Resource 'ora.cssd' failed during Clusterware stack start.

ocssd.trc shows this message repeating for 10 minutes:

2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmvDiskVerify: Successful discovery of 0 disks
2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2026-07-15 10:23:54.351 : CSSD:1956423232: [ INFO] clssnmvFindInitialConfigs: No voting files found
2026-07-15 10:23:54.353 : CSSD:1956423232: [ INFO] (:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds

Cause

The error appears if you have disabled asmlib filtering. Linux tends to change disk device ownership to root. Disabling filtering breaks a handler that tends to change disk device ownership back to oracle.

Oracle ships a per-event ownership handler (/usr/lib/oracleasm/iofilter-asm-disk-addmap, invoked by udev). When filtering is disabled, the handler exits before reaching its chown. With no rule asserting ownership, udev’s defaults set devices to root:disk whenever device nodes are reprocessed or recreated.

1. Workaround while root.sh is running

While root.sh is running, you have plenty of time to correct the underlying issue. Run:

ls -Ll /dev/disk/by-label/ORA_ASM_GRID1_0?

If you see root ownership

brw-rw----. 1 root   disk 8, 193 Jul 26 12:52 /dev/disk/by-label/ORA_ASM_GRID1_01

and so on, then simply run

chown oracle:dba /dev/disk/by-label/ORA_ASM_GRID1_0?

root.sh will resume and run to successful completion. Finish the gridSetup.sh installation. Chances are, the system will give you no trouble after that, even if you reboot the cluster.

2. Enable filtering

crsctl stop crs
or
crsctl stop has
oracleasm configure -f y
Configuration changes only come into effect after the 
Oracle ASM system service is restarted. 
Please run 'systemctl restart oracleasm' after making changes.
systemctl restart oracleasm
crsctl start crs
or
crsctl start has

Caution: my own testing shows unless you restart ASM, filtering will not protect your data as it is designed to.

3. udev rule

If you have decided not to implement filtering, then install this file at /etc/udev/rules.d/99-oracle-asm.rules. That way, whenever something else changes device ownership to root, the rule will change it back. “Something else” is any non-Oracle tool, such as partprobe.

# Brian Fitzgerald
# 2026-07-22

# RHEL 9 / ASMLIB 3 / grid 19c workaround for gridSetup.sh, root.sh
# failing on node a, step 16 'InitConfig', and on node b, step 17, 'StartCluster'.
# ocssd.trc was showing "clssnmvDiskVerify: Successful discovery of 0 disks"
#
# The rule fires whenever a disk is discovered, or is written to and closed.
#
# Firing condition:
# 1. block device
# 2. labeled with oracleasm createdisk

# Action:
# 1. Change the ownership to oracle:dba
# 2. Change the mode to 0660

SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="oracleasm", OWNER="oracle", GROUP="dba", MODE="0660"

Run:

udevadm control --reload-rules
udevadm trigger --subsystem-match=block

Conclusion

The launch failure is a configuration interaction, and any of the three fixes above closes it permanently.