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

重新启动系统，在启动到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）挂载光盘进入救援模式

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

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

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

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

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

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

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

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

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

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

（5）重启系统

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

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

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

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

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

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

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

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