必须安装libnsl包，而非compat-libnsl；RHEL 8+系统中libnsl.so.1已从glibc剥离，需单独安装官方libnsl包（如libnsl-2.28-164.el8.x86_64），硬链接libnsl.so.2.0.0会导致运行时符号错误。
直接装 libnsl 包，别找 compat-libnsl
Oracle 19c（含 runinstaller、perl、sqlplus）在 RHEL 8 / CentOS 8 / Oracle Linux 8 / Rocky Linux 8 等 glibc ≥2.28 的系统上，硬依赖 libnsl.so.1 这个 soname。它已从 glibc 主体中剥离，不再随系统默认安装。
官方仓库里提供的是 libnsl 包（例如 libnsl-2.28-164.el8.x86_64），不是叫 compat-libnsl 或 libnsl-compat 的包——后者在 RHEL/CentOS 8+ 官方源中根本不存在，是 RHEL 7 时代的命名残留，搜错包反而可能引入冲突。
- root 下执行：
yum install -y libnsl（RHEL/CentOS/OL 8）或dnf install -y libnsl（Rocky/AlmaLinux） - OpenEuler 用户应装
libnsl2，再按需软链或从 Oracle 提供的 stubs 目录复制libnsl.so.1 - 若提示
No package libnsl available，检查/etc/yum.repos.d/下 BaseOS 或 AppStream 仓库是否启用（enabled=1）
别用 ln -s libnsl.so.2.0.0 libnsl.so.1 硬链接
/lib64/libnsl.so.2.0.0 是 glibc 2.28+ 重构后的 ABI，导出符号集（如 gethostbyname_r@GLIBC_2.2.5）和 Oracle 所需的 libnsl.so.1 不兼容。硬建软链接会导致运行时出现 symbol lookup error 或段错误，且问题常延迟暴露——比如数据库实例能启动，但 tnsping 返回 TNS-12545，lsnrctl start 失败，排查成本远高于重装。
- 验证是否误建链接：
ls -l /lib64/libnsl.so*，若看到libnsl.so.1 -> libnsl.so.2.0.0就是风险状态 - 已误建的，先
rm /lib64/libnsl.so.1，再重装libnsl包 - 离线环境无法 yum 时，应从同版本 OS 镜像提取
libnsl-*.rpm，用rpm -ivh --nodeps应急安装（仅限无其他选择）
CV_ASSUME_DISTID=RHEL7.6 是辅助手段，不是替代方案
即使设置了 CV_ASSUME_DISTID=RHEL7.6，若 libnsl.so.1 确实缺失，仍会报 INS-08101 或 libnsl.so.1: cannot open shared object file。这个变量只影响安装器对操作系统兼容性的判断逻辑，不解决底层动态库加载失败的问题。
- 变量名必须严格为
CV_ASSUME_DISTID（不是CV_ASSUMED_DISTID或CV_ASSUME_DIST） - 值推荐设为
RHEL7.6（Oracle 19c 官方认证最稳的 RHEL 版本） - 设置后仍需确保
libnsl已安装，并用ldd /u01/app/oracle/product/19.0.0/dbhome_1/perl/bin/perl | grep libnsl验证是否显示libnsl.so.1 => /lib64/libnsl.so.1
预装包 oracle-database-preinstall-19c 不自动修复已卸载的 libnsl
该预装包声明了对 libnsl 的依赖，但不会在 libnsl 已被卸载的情况下主动拉取并安装它。也就是说，如果你系统曾装过又删掉 libnsl，仅装预装包是不够的。
- 安装预装包前，建议先手动确认：
rpm -q libnsl或find /lib64 -name "libnsl.so.1" - 预装包安装后，仍需运行
ldd检查关键二进制（如perl、sqlplus）是否真正加载到libnsl.so.1 - 不要依赖
LD_LIBRARY_PATH临时绕过——Oracle 安装器自身进程（非用户 shell）不读该变量，改了也无效
实际修复中最容易被忽略的点：libnsl 安装后无需任何路径配置，系统动态链接器会自动在 /lib64 中找到它；但很多人卡在“明明装了却还报错”，往往是因为之前建过软链接没清理干净，或者 yum 源没启用导致装的是假包。
