root.sh卡在“creating and starting oracle instance”等阶段，本质是oraagent.bin依赖systemd-logind、dbus未就绪或/etc/hosts解析错误；需启用systemd-logind与dbus，禁用127.0.0.1解析，修复orainventory权限，并确认安装路径为db_home而非grid_home。
root.sh 卡在 “Creating and starting Oracle instance” 或 “Waiting for agent startup”
这是最常见卡点，本质是 root.sh 启动的 oraagent.bin 进程依赖系统服务（如 systemd-logind、dbus）或网络配置未就绪。CentOS 7.9 最小化安装默认不启动 systemd-logind，而 Oracle 19c 的集群件（即使单机也调用部分 CRS 组件）会尝试连接 D-Bus session bus 并检查登录会话状态。
实操建议：
- 确认
systemd-logind已启用并运行：systemctl is-active systemd-logind；若为inactive，执行systemctl enable --now systemd-logind - 检查 D-Bus 是否可用：
busctl list-names | grep -i oracle，若报错或无输出，重启 dbus：systemctl restart dbus - 临时绕过登录会话检查（仅调试用）：
export CV_ASSUME_DISTID=RHEL7.6再重跑root.sh，但该变量不能替代真实服务修复 - 确保
/etc/hosts中主机名能正向/反向解析，且不指向127.0.0.1（例如写成127.0.0.1 localhost.localdomain localhost会导致 CRS 误判本机为 loopback）
root.sh 卡在 “Updating inventory” 或长时间无响应
根本原因是 oraInst.loc 指向的 oraInventory 目录权限或属组错误，或该目录被其他进程（如另一个未退出的 runInstaller）占用。Oracle 安装程序在 root.sh 阶段需以 root 身份写入 inventory，若 /u01/app/oraInventory 所有者不是 root:oinstall，或 oinstall 组对目录无写权限，就会挂起等待锁释放。
实操建议：
- 检查 inventory 目录权限：
ls -ld /u01/app/oraInventory，正确应为drwxrwxr-x 3 root oinstall - 修复权限：
chown -R root:oinstall /u01/app/oraInventory，再chmod -R 775 /u01/app/oraInventory - 确认无残留进程：
ps -ef | grep -i "ora|inst"，杀掉所有非关键的oracle或root下的安装相关进程 - 删掉 inventory 下的
locks子目录（如有）：rm -rf /u01/app/oraInventory/locks
root.sh 卡在 “Running rootwallet.sh” 或 “Configuring Oracle Grid Infrastructure”
这说明你实际在运行 GI（Grid Infrastructure）组件，而非纯数据库软件安装。Oracle 19c 单机部署虽可跳过 GI，但若解压的是完整介质包（含 grid/ 目录）且误触发了 GI 安装流程，root.sh 就会尝试启动 ohasd 和 crsd —— 这些服务在 CentOS 7.9 上依赖 systemd 的特定单元文件和内核模块（如 oracleasm），缺一不可。
实操建议：
- 确认你安装的是数据库软件（
db_home）还是 GI 软件（grid_home）：检查解压路径下是否存在grid/目录；若存在且你不需要 RAC 或 ASM，**不要运行该目录下的root.sh** - 若已误运行，先清理：
cd /u01/app/19.0.0/grid/crs/install && ./roothas.pl -deconfig -force -verbose（需 root 权限） - 纯数据库部署请严格使用
db_home目录下的root.sh，且确保未设置ORACLE_HOME指向 grid 目录 - 检查
/etc/oracle/olr.loc是否残留旧配置，有则手动删除
为什么加了 CV_ASSUME_DISTID=RHEL7.6 还卡住？
CV_ASSUME_DISTID 只影响安装前的兼容性检测逻辑，它不解决 root.sh 运行时真实的系统服务缺失、权限错误或网络配置问题。很多用户把它当成“万能开关”，结果掩盖了真正要修的底层缺陷。
最容易被忽略的点：
-
/etc/hosts中主机名解析必须走真实 IP，不能靠127.0.0.1回环；否则 CRS 初始化阶段会反复尝试连接自身失败 -
oracle用户的~/.bash_profile中若提前设置了ORACLE_HOME或PATH指向未完成安装的路径，root.sh可能加载错误环境导致命令找不到 - SELinux 虽设为
disabled，但若只是改了配置没重启，getenforce仍返回Enforcing，会静默拦截 socket 创建
