openEuler系统启动危机：Failed to execute /sbin/init与/bin/sh错误的深度诊断与修复实录

1. 当openEuler系统拒绝启动时：一场与时间的赛跑

凌晨三点，服务器告警短信突然响起——这绝对是运维人员最不想看到的场景。一台运行openEuler 22.03的生产服务器在例行重启后，屏幕上赫然显示着两行刺眼的错误信息：

Failed to execute /sbin/init Failed to execute /bin/sh

这种情况意味着系统连最基本的初始化进程和shell环境都无法启动，相当于电脑"植物人"状态。作为经历过多次类似故障的老兵，我想分享一套经过实战检验的完整诊断与修复流程。

这类问题通常由三种原因导致：关键文件丢失（比如/lib64目录被误删）、文件权限异常（比如错误的chmod操作）、或者存储设备损坏。根据我的经验，80%的情况都是动态链接库目录/lib64被意外清理导致的。接下来我们就从最紧急的救援操作开始，一步步找回丢失的系统。

2. 急救第一步：进入救援环境的三种姿势

2.1 官方ISO救援模式实战

首先尝试最正统的救援方式——使用openEuler安装ISO。将镜像写入U盘后从光驱启动，在启动菜单选择"Rescue a openEuler system"。但这里有个坑：某些版本的救援模式可能会卡在加载阶段。如果遇到这种情况不要慌，我通常会直接改用单用户模式。

2.2 单用户模式的魔法按键

在GRUB启动菜单界面（启动时快速按ESC或Shift键），选中正常启动项后按"e"进入编辑模式。找到以"linux"开头的行，在行尾追加：

rw rd.break

然后按Ctrl+X启动，这时会进入紧急模式。理想情况下应该能看到熟悉的root提示符，但有时候连这个都会失败——就像我上次遇到的案例，因为/bin/sh本身也损坏了。

2.3 专用救援镜像的妙用

当标准方法都失效时，华为官方提供的专用救援镜像就是救命稻草。这个镜像默认root密码是Huawei@SYS3（建议提前记在小本本上）。使用时有个关键技巧：先通过lsblk确认根分区位置，通常是/dev/mapper/openeuler-root这样的设备名。挂载时务必加上--make-private参数：

mount --make-private /dev/mapper/openeuler-root /mnt

否则后续操作可能会遇到设备忙的错误。

3. 深度诊断：为什么连init都罢工了

3.1 动态链接库的蝴蝶效应

进入救援环境后，第一件事就是检查/sbin/init和/bin/sh的完整性。执行以下命令查看依赖关系：

chroot /mnt ldd /sbin/init chroot /mnt ldd /bin/sh

如果看到"not found"提示，基本可以确定是动态链接库缺失。我遇到过最夸张的情况是整个/lib64目录被某位同事误执行了rm -rf。这时候ls -l /mnt/lib64会显示一个空荡荡的目录，而正常系统这里应该有200+个.so文件。

3.2 权限问题的蛛丝马迹

如果文件存在但依然报错，就要检查权限了。健康的init程序权限应该是：

-rwxr-xr-x 1 root root 1.5M Mar 15 2022 /sbin/init

特别注意三个关键点：必须有可执行权限(x)、所属用户必须是root、不能设置奇怪的扩展属性。曾经有个故障是因为有人误执行了chmod -R 777 /，导致SELinux安全上下文全部丢失。

4. 从灾难中恢复：两种救命方案

4.1 同环境克隆方案（推荐）

如果有其他相同版本的正常节点，可以快速打包其库文件：

# 在正常节点执行 tar -zcvf lib64_backup.tar.gz /usr/lib64/* # 在故障机通过SSH或U盘获取后 tar -xzvf lib64_backup.tar.gz -C /mnt/usr/lib64

这里有个细节：openEuler的库文件实际存放在/usr/lib64，但会通过链接映射到/lib64。恢复后务必检查软链接：

ls -l /mnt/lib64

应该能看到指向../usr/lib64的符号链接。

4.2 手动重建方案

当没有可用的参考机器时，可以尝试从rpm包重建。首先挂载ISO到/mnt/iso，然后查询包含库文件的包：

for lib in $(chroot /mnt ldd /sbin/init | grep "not found" | awk '{print $1}'); do rpm -qf /usr/lib64/$lib --root=/mnt done

找到缺失的包后，用rpm2cpio工具解压：

rpm2cpio /mnt/iso/Packages/glibc-2.34-10.oe1.x86_64.rpm | cpio -idv -D /mnt

这个过程比较繁琐，我上次修复时整整处理了38个依赖包。

5. 防患于未然：运维人员的避险指南

5.1 关键目录保护技巧

建议给系统关键目录加把锁：

chattr +i /usr/lib64 /lib64 /sbin/init /bin/sh

这样即使root用户也无法误删。还可以配置auditd监控关键文件变动：

auditctl -w /usr/lib64 -p wa -k critical_libs

5.2 制作系统快照

定期使用xfsdump或btrfs snapshot创建系统分区快照。我现在的习惯是每次yum更新前都做一次快照：

xfsdump -l 0 -L "base_state" -M "openEuler_$(date +%F)" \ -f /backup/root_$(date +%s).img /dev/mapper/openeuler-root

5.3 救援工具包常备清单

我的应急U盘里永远存放着：

1. 对应版本的openEuler安装ISO
2. SystemRescue最新镜像
3. 预编译的静态链接版busybox
4. 公司内网跳板机的SSH密钥对

那次凌晨三点的故障后，我花了整整六小时才恢复系统。现在每次维护关键服务器前，都会条件反射地检查三遍命令——有些教训，一次就够记一辈子。