使用 x2openEuler 工具升级 SUSE12 过程中升级前检查中断的可能原因及解决方案 一、问题现象近期，遇到多起 SUSE12 升级过程中升级前检查中断的事件，具体报错现象如下图所示：经查看日志，发现是在收集硬件信息时报错，即 x2openEuler-client hardware-collect 命令执行失败：进一步查看升级日志，并且在待升级节点手动执行 x2openEuler-client hardware-collect 命令，均发现以下报错信息：报错显示：操作系统上没有发现 /usr/sbin/lspci 命令二、原因分析以上报错由一系列原因导致：① SUSE12 实际存在且可以执行 lspci 命令② 通过执行 which lspci 命令发现其位于 /sbin/ 目录中③ SUSE12 系统中 /usr/sbin/ 目录和 /sbin/ 目录并不是软链接关系④ x2openEuler 工具收集硬件信息时执行的 lspci 命令是带绝对路径的 /usr/sbin/lspci 最终导致硬件信息收集失败，检查中断三、解决方案此问题并非必现，具体出现原因可能与用户环境配置相关。若遇到此问题可以创建一个软连接 /usr/sbin/lspci 到 /sbin/lspci 最终还是建议工具能够注意并修复一下这个问题，避免不必要的麻烦

使用 x2openEuler 升级过程遇到 can not clean repo info before upgrade 报错的解决方案 1 问题背景近期又遇到多起在升级过程中报错，报错信息为 “can not clean repo info before upgrade”，如下图所示：这是因为在待升级节点执行 dnf clean all 命令时报错此时很多朋友会有疑问：我的操作系统没有装 dnf ，我的操作系统上不能装 dnf ，等等，那么为什么要去执行 dnf clean all 命令呢？这要从工具升级的原理说起，在报错信息的上面几行有这样的信息：...... [ INFO ] - [initramfs]: start upgrade your system by dnf [ INFO ] - [initramfs]: start construct dnf [ INFO ] - [initramfs]: replace yum to dnf. [ INFO ] - [initramfs]: start to delete yum [ INFO ] - [initramfs]: construct dnf in your system success [ INFO ] - [initramfs]: your system will use dnf to upgrade. ......明显可以看到，工具做了一系列操作：开始构建 dnf使用 dnf 去替换 yum开始删除 yum成功在你的操作系统上构建 dnf你的系统将使用 dnf 去升级dnf 是 yum 的下一代版本，dnf 比 yum更快速和高效，并且 dnf 在解决软件包依赖关系方面比 yum 更强大和智能，能够更好地处理复杂的依赖关系，这也是为什么工具或者以后的操作系统都是用 dnf 作为包管理工具的原因既然知道了症结所在，那么就可以对症下药了！2 规避方案2.1 执行 dnf clean all 命令查看报错在待升级节点手动执行 dnf clean all 命令查看具体报错：报错显示是和 openssl 的库文件有关，具体信息为：“这个错误表明你的系统中的 libldap 库试图使用 EVP_md2 这个加密库函数，但是这个函数在当前系统中的 OpenSSL 版本中不存在或未定义。 EVP_md2 是一个散列函数，用于计算 MD2 散列值，但在较新版本的OpenSSL 中，可能已经将 MD2 作为过时的算法移除了。”2.2 查看 openssl 版本首先执行 rpm -qa | grep openssl 命令查看系统安装的 openssl 版本：系统安装的 openssl 版本为 1.0.2k其次执行 openssl version -a 查看系统当前在用的 openssl 版本：系统在用的 openssl 版本为 1.1.1w系统安装的 openssl 版本和在用的版本不同，那么高版本的 openssl 必然是编译安装的，在编译安装 openssl 时，又必须需要指定高版本 openssl 库文件的位置，否则不能正常使用2.3 查看指定库的位置在 Centos 操作系统中，共有三种指定库文件位置的方式：将库文件所在目录添加到 /etc/ld.so.conf 文件中将库文件所在目录添加到指定文件，并将此文件放在 /etc/ld.so.conf.d/ 目录中将库文件所在目录添加到 LD_LIBRARY_PATH 环境便变量中（1）针对前两种指定库文件的方式，可以使用以下方法排查：① 确定编译安装的 openssl 库文件所在的目录：② 查找该目录具体写到哪个地方了：③ 从查找到的文件中注释掉该目录，之后执行 ldconfig 刷新动态链接库④ 执行 dnf clean all 命令，若无报错则可以到前端点击“重试”按钮继续升级（2）针对最后一种指定库文件的方式，可以使用以下方法排查：① 确定编译安装的 openssl 库文件所在的目录：② 查看 LD_LIBRARY_PATH 变量是否有定义此目录③ 若有则从该变量中剔除该目录④ 执行 dnf clean all 命令，若无报错则可以到前端点击“重试”按钮继续升级

使用 x2openEuler 工具升级后 PAM 模块丢失导致登录失败的解决方案 1 问题背景时间：2023 年 12 月 11 日需求：使用 x2openEuler 工具完成从 CentOS 7.6 到 openEuler 22.03 LTS SP1 的升级后，在终端界面登陆时出现登录失败的报错，但可以使用 SSH 远程登录系统，如下图所示2 问题分析及复现2.1 问题分析在排除了密码输入错误等因素后，使用 SSH 远程登录系统，查看 /var/log/secure 日志，内容如下从日志可以看出，在登录系统时，要进行 PAM 认证，但是找不到认证需要的 pam_tally2.so 库文件，导致认证失败而拒绝登录执行 grep -r pam_tally2.so /etc/pam.d 命令，查看哪个配置文件在调用这个库文件从查询结果可以看到，/etc/pam.d/system-auth 这个配置文件调用此库文件然而在全新安装的 openEuler 22.03 LTS SP1 操作系统中，查看这个配置文件发现调用的是 pam_faillock.so 这个库文件查阅资料后得知，新的 pam 认证软件包弃用了 pam_tally2 模块，而是采用 pam_faillock 模块，那么出现了一个问题：在升级到 openEuler 22.03 LTS SP1 操作系统后，对应的 pam 软件包也被升级了，但是怎么还使用了旧版本的模块呢？查看 /etc/pam.d 目录下的所有文件，出现了名为 system-suth.rpmsave 的文件，查看此文件的内容，发现在升级前配置过连续登录失败锁定用户的安全加固项，在升级系统生成新配置文件时，引用了错误的库文件为什么会出现 *.rpmsave 文件呢？这是由构建 RPM 包时的 SEPC 文件决定的。若使用了 %config 关键字标记了配置文件，表示在升级 rpm 包时，若旧配置文件没有被修改过，那么使用新配置文件覆盖旧配置文件，旧配置文件被删除；若旧配置文件被修改过，那么仍然使用新配置文件覆盖旧配置文件，但旧配置文件会以 *.rpmsave 的形式保留下来2.2 问题复现2.2.1 准备工作准备如下表所示的机器 版本号用途源操作系统CentOS 7.6配置安全加固项后升级目标操作系统openEuler 22.03 LTS SP1使用终端登录验证2.2.2 源操作系统配置（1）配置连续登录失败锁定账户的安全加固项# 配置连续登录失败锁定账户的安全加固项 $ sed -i '/#%PAM-1.0/a auth \t required \t pam_tally2.so deny=3 lock_time=30 even_deny_root root_unlock_time=30 per_user reset' /etc/pam.d/system-auth 参数说明： pam_tally2.so 使用 pam_tally2.so 模块，不同 pam 版本调用的模块可能不同 deny=3 用户连续输入错误密码的次数 lock_time=300 普通用户连续输入错误密码后锁定时间，单位：秒 even_deny_root 对 root 用户生效 root_unlock_time=30 root 用户连续输入错误密码后锁定时间，单位：秒 per_user reset 解锁时间到了以后，清除用户锁定状态重启操作系统，连续三次输入错误密码，查看配置是否生效# 查看 root 用户登录失败记录 $ pam_tally2 --user root Login Failures Latest failure From root 2 12/27/23 10:30:30 tty1（2）使用 x2openEuler 工具升级到目标操作系统2.2.3 目标操作系统验证在 tty 终端登录系统报错使用 SSH 远程登录后，查看 /var/log/secure 日志# 查看 /var/log/secure 日志 $ vim /var/log/secure ...... Dec 27 11:23:37 localhost login[5251]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open shared object file: No such file or directory Dec 27 11:23:37 localhost login[5251]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so Dec 27 11:23:41 localhost login[5251]: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root" Dec 27 11:23:43 localhost login[5251]: FAILED LOGIN SESSION FROM tty1 FOR root, Module is unknown报错内容与生产环境一致，成功复现了问题3 解决措施3.1 如何临时补救共有两种临时补救方案，详见下文3.1.1 补全缺失的库文件补救思路：根据报错内容，从备份目录 /.osbak 中找到缺失的库文件，然后将库文件复制到当前操作系统的对应目录存在问题：因为新版本不再使用这个库文件，人为复制过来调用，会造成额外的资源消耗，并且在以后升级该软件包时也会遇到一些问题，治标不治本操作流程：# 查看 /var/log/secure 日志 $ vim /var/log/secure ...... Dec 27 11:23:37 localhost login[5251]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open shared object file: No such file or directory Dec 27 11:23:37 localhost login[5251]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so Dec 27 11:23:41 localhost login[5251]: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root" Dec 27 11:23:43 localhost login[5251]: FAILED LOGIN SESSION FROM tty1 FOR root, Module is unknown # 查找缺失的库文件 $ find / -name pam_tally2.so /.osbak/usr/lib64/security/pam_tally2.so # 复制查找到的库文件到 /usr/lib64/security 目录 $ cp /.osbak/usr/lib64/security/pam_tally2.so /usr/lib64/security/能够成功在 tty 终端登录系统3.1.2 修改配置文件补救思路：根据报错内容，查找是哪个配置文件调用了缺失的库文件，然后注释掉配置文件中调用缺失模块的代码存在问题：相比 3.3.1 中的解决办法，不会造成额外资源消耗，说得上是比较稳妥的处理办法，但是毕竟和新版本的配置文件不同，可能影响后续的配置操作流程：# 查看 /var/log/secure 日志 $ vim /var/log/secure ...... Dec 27 11:23:37 localhost login[5251]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open shared object file: No such file or directory Dec 27 11:23:37 localhost login[5251]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so Dec 27 11:23:41 localhost login[5251]: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root" Dec 27 11:23:43 localhost login[5251]: FAILED LOGIN SESSION FROM tty1 FOR root, Module is unknown # 查找缺失的库文件被哪个配置文件调用 $ grep -r pam_tally2.so /etc/pam.d/ /etc/pam.d/system-auth:auth required pam_tally2.so deny=3 lock_time=30 even_deny_root root_unlock_time=30 per_user reset # 注释或删除相应的代码 $ sed -i '/pam_tally2.so/ s/^/#/' /etc/pam.d/system-auth能够成功在 tty 终端登录系统3.2 如何完美解决共有两种临时解决方案，详见下文3.2.2 使用新配置文件覆盖旧文件解决思路：根据报错内容，查找是哪个配置文件调用了缺失的库文件，然后查看该配置文件的同级目录下，是否有与该配置文件同名但是后缀为 .rpmnew 的文件，使用 *.rpmnew 文件覆盖旧文件方案特点：这是软件包升级后根据旧配置文件生成的新配置文件，可以大胆正常使用，但前提是生成了 *.rpmnew 配置文件操作流程：# 查看 /var/log/secure 日志 $ vim /var/log/secure ...... Dec 27 11:23:37 localhost login[5251]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open shared object file: No such file or directory Dec 27 11:23:37 localhost login[5251]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so Dec 27 11:23:41 localhost login[5251]: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root" Dec 27 11:23:43 localhost login[5251]: FAILED LOGIN SESSION FROM tty1 FOR root, Module is unknown # 查找缺失的库文件被哪个配置文件调用 $ grep -r pam_tally2.so /etc/pam.d/ /etc/pam.d/system-auth:auth required pam_tally2.so deny=3 lock_time=30 even_deny_root root_unlock_time=30 per_user reset # 查看 /etc/pam.d 目录下的所有相关文件 $ cd /etc/pam.d $ ls -l | grep system-auth -rw-r--r-- 1 root root 1133 12月 27 14:29 system-auth -rw-r--r--. 1 root root 1031 11月 21 21:10 system-auth-ac -rw-r--r-- 1 root root 1496 3月 22 2023 system-auth.rpmnew # 备份旧配置文件 $ mv system-auth system-auth.bak # 恢复新配置文件 $ cp system-auth.rpmnew system-auth能够成功在 tty 终端登录系统3.2.1 从 rpm 包中恢复配置文件解决思路：先查找缺失的库文件被哪个配置文件调用，然后查找这个配置文件来源于哪个软件包，从软件包中恢复该配置文件方案特点：从 rpm 包中恢复出全新的配置文件，替换旧文件，缺点是需要重新配置安全加固项操作流程：（1）安装基础工具# 安装 yumdownloader 包下载工具 $ yum install -y dnf-plugins-core # 安装 cpio 备份工具 $ yum install -y cpio（2）恢复配置文件# 查看 /var/log/secure 日志 $ vim /var/log/secure ...... Dec 27 11:23:37 localhost login[5251]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open shared object file: No such file or directory Dec 27 11:23:37 localhost login[5251]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so Dec 27 11:23:41 localhost login[5251]: pam_succeed_if(login:auth): requirement "uid >= 1000" not met by user "root" Dec 27 11:23:43 localhost login[5251]: FAILED LOGIN SESSION FROM tty1 FOR root, Module is unknown # 查找缺失的库文件被哪个配置文件调用 $ grep -r pam_tally2.so /etc/pam.d/ /etc/pam.d/system-auth:auth required pam_tally2.so deny=3 lock_time=30 even_deny_root root_unlock_time=30 per_user reset # 查找配置文件来源于哪个 rpm 包 $ rpm -qf /etc/pam.d/system-auth pam-1.5.2-6.oe2203sp1.x86_64 -------------------------------以下内容在 /root 目录操作------------------------------- $ cd /root # 下载查找到的 rpm 包 $ yumdownloader pam-1.5.2-6.oe2203sp1.x86_64 # 查看下载的 rpm 包 $ ls -l pam-1.5.2-6.oe2203sp1.x86_64.rpm -rw-r--r-- 1 root root 448921 12月 27 14:49 pam-1.5.2-6.oe2203sp1.x86_64.rpm # 执行以下命令恢复配置文件 $ rpm2cpio pam-1.5.2-6.oe2203sp1.x86_64.rpm | cpio -idv ./etc/pam.d/system-auth ./etc/pam.d/system-auth 4127 块 # 在当前目录下会生成恢复的配置文件 $ ls -l ./etc/pam.d/ 总用量 4 -rw-r--r-- 1 root root 1496 12月 27 14:54 system-auth # 备份旧配置文件 $ mv /etc/pam.d/system-auth /etc/pam.d/system-auth.bak # 恢复新配置文件 $ cp etc/pam.d/system-auth /etc/pam.d/能够成功在 tty 终端登录系统