根本原因是udev规则未生效或ASM磁盘设备节点权限不足，导致kfod调用底层open()时阻塞；需检查grid用户对/dev/asm-或/dev/sd的读权限、验证udev规则触发及多节点一致性。
DBCA卡在“Scanning ASM disks”界面，kfod 命令手动执行也卡住
根本原因通常不是磁盘本身有问题，而是 kfod 在调用底层设备接口时被阻塞——最常见的是 udev 规则未生效或权限没落到实际设备节点上。dbca 启动时会以 oracle 用户（或 grid 用户）调用 kfod 扫描 /dev/oracleasm 或裸设备路径，若该用户对底层块设备（如 /dev/sdb、/dev/asm-disk1）无读权限，kfod 就会 hang 住，不报错也不退出。
实操建议：
- 切到 grid 用户，手动运行：
kfod disk=asm verbose=true，观察是否卡住、卡在哪一行输出（通常停在 “Reading disk…” 后） - 检查
/dev下对应 ASM 磁盘的属主和权限：ls -l /dev/asm*或ls -l /dev/sd*，确认 oracle/grid 用户能否读取（至少要有crw-rw----且组为asmadmin或dba） - 别只看 udev 规则文件（如
/etc/udev/rules.d/99-oracle-asmdevices.rules）是否存在，要验证规则是否真正触发：执行udevadm test /sys/block/sdb，看输出里有没有OWNER="grid"、GROUP="asmadmin"这类赋值 - 如果用的是 multipath 设备，确保
/dev/mapper/mpathx节点权限正确，且 udev 规则匹配的是multipath设备而非底层sdx
udev 规则写了但 /dev/asm-disk* 权限仍是 root:root
udev 规则没生效，大概率是规则文件名或语法不满足触发条件，或者规则中用了不稳定的匹配项（比如仅靠 KERNEL=="sd?" 匹配所有 sda~sdz，结果把系统盘也卷进来了，导致规则被跳过）。
实操建议：
- 规则文件名必须以数字开头、.rules 结尾，且数字越小优先级越高；避免用
99-xxx.rules，改用60-asm.rules更稳妥 - 不要只依赖
KERNEL，加上唯一性更强的匹配：用SUBSYSTEM=="block"+ATTR{ro}=="0"+ATTRS{model}=="Virtual_Disk"（VM 环境）或ATTRS{wwn}=="0x..."（物理环境） - 赋权语句必须用
OWNER/GROUP/MODE，不能写成run+="/bin/sh -c 'chown ...'"—— udev 不支持这种间接方式 - 重载后务必执行：
udevadm control --reload-rules && udevadm trigger --subsystem-match=block，再检查设备节点
kfod 超时时间不可配，但能绕过扫描阶段
kfod 没有公开参数控制超时，它的 hang 是底层 open() 系统调用阻塞导致的，DBCA 内部调用它时也没有设置 timeout。但你可以让 DBCA 跳过自动扫描，直接指定已知可用磁盘。
实操建议：
- 启动 DBCA 图形界面前，先设环境变量：
export ORACLE_ASM_DISKS="/dev/asm-disk1,/dev/asm-disk2"（注意路径必须真实存在且可读） - 或者用静默建库方式，显式传参：
dbca -silent -createDatabase ... -storageType ASM -asmsnmpPassword ... -diskGroupName DATA -asmDiskString '/dev/asm-disk*' - 注意
-asmDiskString的值会被 DBCA 传给kfod diskstring=...，所以必须确保该 glob 能精确匹配到已有权限的设备，否则仍会卡 - 这个方法治标不治本——权限问题还在，只是绕开了自动发现环节；后续 asmca、srvctl start asm 等操作仍可能因同样问题失败
RAC 环境下各节点 udev 规则不一致导致部分节点建库成功、部分卡住
这是最容易被忽略的点：RAC 多节点共享同一套存储，但每个节点的 udev 规则、内核模块加载状态、甚至 SCSI 设备识别顺序都可能不同。一个节点上 /dev/sdb 是 ASM 盘，另一个节点上可能是 /dev/sdc，而 udev 规则若硬编码了 sdb，另一节点就完全失效。
实操建议：
- 所有节点统一用 WWN 或 UUID 匹配设备，而不是依赖
sdx名字：ATTRS{wwn}=="0x5000c500a1234567" - 在每台节点上分别运行：
scsi_id -g -u -d /dev/sdb和udevadm info --name=/dev/sdb | grep wwn，确认输出一致 - 检查
oracleasm listdisks输出是否所有节点完全一样；不一样说明 oracleasm init 或 scandisks 没跑通，根源还是底层设备权限或oracleasm服务状态 - 别忘了验证 grid 用户在所有节点都能无密码 ssh 互通——DBCA 集群建库时会远程拉起其他节点的
kfod，若 ssh 卡住，也会表现为“扫描中…”
udevadm trigger，或者 oracleasm scandisks 报了错但被 DBCA 的图形界面吞掉了。 
