新闻动态
当前位置:首页 > 新闻动态
【常见问题6】 用户误操作致系统库文件丢失导致无法启动
2024-05-24

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

 一. 问题描述 

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

  二. 过程分析 
(1)在启动界面打印更多日志

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

3.png

删除 rhgb 和quiet 参数

3.png

增加配置串口参数

console=tty0 console=ttyS0,115200,随后按Ctrl+x启动:

3.png

(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)挂载光盘进入救援模式

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

a. 从光盘启动,选择进入“Troubleshooting”:

3.png

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

3.png

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

3.png

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

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

a. 发现缺失 libcrypto.so.1.1 文件:

3.png

4.png

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

3.png

c. 将该文件拷贝还原到异常系统的对应路径下

d. 继续使用rpm –Va检查,发现还有丢失libssl.so.1.1.1k文件,同样从正常系统中还原该文件,直到校验正常无丢失文件

3.png

4.png

(5)重启系统

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

3.png

 三. 问题根因 

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

 四. 解决方案 

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

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

 五. 预防措施

1)定期备份

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

2)谨慎操作

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

3)监控系统日志

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

4)使用事务型文件系统

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


关注我们

Copyright © 2024 浪潮信息 鲁ICP备13028953号-12

售前咨询

售后服务

回到顶部

回到顶部

售前咨询
售后服务