太坏了,谁这么整活别人的Linux?

(首发地址:学习日记 https://www.learndiary.com/2024/04/chmod-chattr-systemd/

大家好,我是“学习日记小店”的店主,在淘宝网活跃着,专注于 Linux 服务。今天我要与大家分享一件之前处理过的 Linux 系统故障案例,这个案例颇具趣味性,我会通过 VirtualBox 虚拟机中的 Ubuntu 20.04 操作系统来重现问题和解决方案。视频演示:【太坏了,谁这么整活别人的Linux?】 https://www.bilibili.com/video/BV1nt421J7Tv/

事情是这样的,有一次我在面对一台已经出现问题的 Linux 系统时,遇到了一个颇具挑战性的启动故障。为了让各位也能身临其境地体验一番,我先展示了一下故障现象,让大家尝试猜测问题所在。屏幕上显示出的是一个由于某种原因导致系统无法正常启动的状态,提示信息“run-init: can't excute '/sbin/init': Permission denied”。

在解决问题的过程中,我采取了直接修改内核引导参数的方法来进行修复。具体操作是在 Grub 启动菜单的内核参数选项中将原本只读的“ro”更改为可读写的“rw”,并在其后追加一条指令“init=/bin/bash”。这样一来,当按下 Ctrl+X 启动系统时,它会跳过原有的初始化流程,直接进入 Bash 环境以便于排查和修复问题。

修复步骤相当直接,只需进入 /lib/systemd 目录下,对 systemd 文件执行 “chattr -i systemd” 去除其不可更改属性,接着使用 “chmod +x systemd” 恢复其可执行权限。这两步操作迅速解决了当时所遇到的问题。

现在让我来解释一下问题的根源。原来,有人故意删除了 Linux 系统内初始化程序 systemd 的可执行权限,并给它加上了不可更改属性,这就导致了系统在启动过程中无法执行关键的 /sbin/init 指向的 systemd,从而无法完成正常的启动序列。

Debian 文档《系统初始化》(见后参考链接1)章节中有提到,系统初始化分为四个阶段,其中最后一阶段便是 /sbin/init 指向的 /lib/systemd/systemd,负责启动后续的各种服务和程序,确保系统正常运作。在这个案例中,正是因为 systemd 文件权限异常,才引发了这次启动失败。

接下来讲解我在修复过程中涉及的内核启动参数修改。在 Arch Linux 的文档《内核参数》(见后参考链接2)中,我提到了“rw”参数,它使得系统在启动时将根分区挂载为可读写状态,允许我们对文件系统进行必要的修改。而“init”参数则是用来指定替代的初始化程序,在本例中,我们将它设为了“init=/bin/bash”,这样便可以立即进入bash环境进行修复工作。

最后,第三个知识点涉及到使用的两个命令:“chmod”用于改变文件权限,其中“-x”标志取消了文件的可执行权限;而“chattr”命令则用于设置文件的特殊属性,如防止文件被修改或新增内容等。

通过以上所述,我已完整还原了那次有趣的Linux故障及其解决过程,希望这些知识能帮助大家更好地理解和应对类似的系统问题。再次感谢大家的关注和收看,期待下次再见!

参考链接

  1. The system initialization https://www.debian.org/doc/manuals/debian-reference/ch03.en.html
  2. Kernel parameters https://wiki.archlinux.org/title/kernel_parameters

发表评论

电子邮件地址不会被公开。 必填项已用*标注