【常见问题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这样的事务型文件系统,这类文件系统提供了更好的数据完整性保护。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值