【常见问题6】 用户误操作致系统库文件丢失导致无法启动

本期为服务器操作系统常见问题第6篇，介绍由于用户误操作导致系统中的库文件丢失或损坏，引起内核无法启动的问题，本文将探讨问题根因，介绍分析过程，并提供相应的解决方案及预防措施。

【问题描述】

用户在系统下运行某压测脚本后，再次重启时，卡在打印显示“Starting Switch Root”的界面，且键盘无响应：

【过程分析】

（1）在启动界面打印更多日志

重新启动系统，在启动到grub界面时，按“e”编辑内核启动参数：

删除 rhgb 和 quiet 参数

增加配置串口参数 console=tty0 console=ttyS0,115200，随后按Ctrl+x启动：

（2）分析串口日志

在抓到的串口日志中，看到宕机时打印出了kernel panic的报错信息：

Starting Switch Root...

[ 11.400319] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

[ 11.410397] CPU: 19 PID: 1 Comm: systemd Not tainted 5.10.134-15.2.15.kos5.x86_64 #1

[ 11.417988] Hardware name: IIMS/IIMS, BIOS 4.1.14 04/04/2021

[ 11.424776] Call Trace:

[ 11.427763] dump_stack+0x5c/0x80

[ 11.431613] panic+0xe7/0x2a9lockingMode: For SPS ME use Heci message

[ 11.435127] do_exit.cold.23+0x57/0xb6

[ 11.439385] do_group_exit+0x3a/0xa000 1C 00 00 00

[ 11.443471] __x64_sys_exit_group+0x14/0x200 00 00

[ 11.448154] do_syscall_64+0x5b/0x1a00 00 00 00 00

[ 11.452329] entry_SYSCALL_64_after_hwframe+0x65/0xca

[ 11.457827] RIP: 0033:0x7f8b33f9890e80300008

[ 11.461846] Code: 89 fa 41 b8 e7 00 00 00 be 3c 00 00 00 eb 14 0f 1f 44 00 00 89 d7 89 f0 0f 05 48 3d 00 f0 ff ff 77 1a f4 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff ff 76 e2 f7 d8 89 05 6a f8 20 00 eb d8 f7 d8 89 05

[ 11.481499] RSP: 002b:00007ffd0a9644f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7

[ 11.489472] RAX: ffffffffffffffda RBX: 00007f8b33fa1210 RCX: 00007f8b33f9890e

[ 11.497081] RDX: 000000000000007f RSI: 000000000000003c RDI: 000000000000007f

[ 11.504695] RBP: 00007f8b3418e4ef R08: 00000000000000e7 R09: 0000000000000000

[ 11.512317] R10: 0000000000000020 R11: 0000000000000246 R12: 00007f8b3418e500

[ 11.519939] R13: 000000000000001a R14: 00007f8b341a81d0 R15: 0000000000000000

[ 11.527649] Kernel Offset: 0x10400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

[ 11.644225] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

（3）挂载光盘救援模式

鉴于系统在本次启动失败前能够正常启动，推测用户在上一次正常使用系统时可能进行了某些不当操作，导致系统无法正常启动。为此，我们将挂载光盘镜像，并尝试利用光盘救援模式访问系统，以检查文件系统的完整性和状态

1. 从光盘启动，选择进入“Troubleshooting”：

b.选择进入“Rescue a KeyarchOS system”：

c. 在弹出的选项中，选择“1”，并输入“chroot /mnt/sysroot”挂载系统分区

（4）校验RPM软件包完整性及恢复丢失的库文件

使用 rpm –Va 校验所有的RPM软件包，检查是否有丢失的文件，通过如下方式修复：

1. 发现缺失 libcrypto.so.1.1 文件：

1. 在正常启动的系统上查找，看到正常存在文件 /usr/lib64/libcrypto.so.1.1

1. 将该文件拷贝还原到异常系统的对应路径下
2. 继续使用rpm –Va检查，发现还有丢失libssl.so.1.1.1k文件，同样从正常系统中还原该文件，直到校验正常无丢失文件

（5）重启系统

退出光盘救援模式，重启系统，可以正常进入系统。

【问题根因】

用户误操作删除了系统库文件libcrypto和libssl后，在系统重新启动时，由于根文件系统中的系统库文件libcrypto和libssl丢失或损坏，导致systemd服务无法重新执行，进而引起内核无法启动并出现panic问题。

【解决方案】

对于操作系统而言，其启动过程的失败通常归咎于文件系统的损坏。因此，在面对系统内核无法正常启动的问题时，关键在于采取一系列措施，如增加打印日志和进入救援模式，以准确定位文件系统损坏的细节。

针对此类问题，通常需要部署一个能够正常启动的操作系统环境。通过对比这个正常环境与故障系统之间的文件系统，特别是关键文件的差异，可以确定问题所在。一旦找到差异点，如根文件系统中存在缺失或损坏的库文件，接下来应从正常运行的系统中提取相应的关键库文件，并将其恢复至故障系统中，以解决启动问题。

【预防措施】

（1）定期备份

定期备份系统库文件，以便在出现问题时能够快速恢复。

（2）谨慎操作

执行系统维护或升级操作时，确保遵循最佳实践，避免意外删除或损坏关键文件。

（3）监控系统日志

定期检查系统日志，以便及时发现潜在的问题并采取措施。

（4）使用事务型文件系统

考虑使用如XFS这样的事务型文件系统，这类文件系统提供了更好的数据完整性保护。