root 密码忘了、sudo 提权失败、系统盘挂载不上、机器重启后停在 emergency shell 里不动——这一类工单我在过去几年里处理过几十次处理路径几乎都指向同一个动作进救援环境把 root 相关的东西改掉。听起来像是个一句话就能说完的操作真上手的时候坑全在细节里根分区是只读的挂不上、LVM 卷没激活、SELinux 上下文被改坏导致下次开机直接卡死、云主机控制台根本进不去 GRUB。这篇就把“救援环境更改 root”这件事从头到尾拆开讲包括救援环境有哪几种形态、改 root 到底在改什么、每种故障场景该走哪条路径、完整命令流程、复杂变形情况怎么处理以及我自己踩过的那些坑。适合有一定 Linux 基础、手上有服务器或者嵌入式设备要维护的朋友看也适合刚接手运维工作、第一次遇到机器起不来的同学对照着操作。1. 先把“救援环境”和“改 root”这两件事讲透很多人对救援环境的理解是“一个能进去敲命令的特殊模式”这个理解不算错但太模糊导致真出问题时不知道该选哪个入口。同样“改 root”这四个字也经常被简化成“改密码”可实际场景里 root 出问题的形态远不止密码这一种。概念没理清操作就会变成试错而救援环境下的试错成本很高——一次误操作可能把本来还能救的数据彻底搞坏。1.1 救援环境到底是什么有哪几种形态救援环境的本质是一个独立于目标系统的临时运行环境。它有自己的内核、自己的根文件系统、自己的一套工具完全不依赖硬盘上那套已经坏掉的配置。打个比方目标系统是间着火的房子救援环境就是你开过来的一辆房车——房子烧了不影响你在房车里住你还能从房车里拿工具进去修。按入口划分常见的有这么几类安装介质自带的救援模式。主流发行版的安装镜像在启动菜单里通常有个救援选项进去后它会尝试探测硬盘上的系统并自动挂载到/mnt/sysroot之类的路径下。优点是工具齐全、有网络配置向导缺点是必须能挂载介质云主机上没有物理光驱就比较麻烦。引导器层面的单用户/紧急模式。在 GRUB 菜单里编辑内核启动参数加上single、emergency、rd.break或者init/bin/bash让系统跳过大部分初始化流程直接给你一个 shell。这是最快的方式但前提是引导器本身没坏、你能看到 GRUB 菜单。独立的 Live 介质。用一个 U 盘或者 ISO 启动一个完整的临时系统然后手工挂载硬盘分区、chroot 进去操作。灵活度最高什么都能修代价是每一步都要手工来。云厂商提供的救援系统。控制台里一般有个“进入救援模式”的按钮点了之后平台会把你的系统盘挂成一块数据盘给你一个临时的 SSH 入口。这个入口通常不带你原来的系统环境需要自己挂载。嵌入式设备的 recovery 分区。手机、路由器、工控板卡这类设备往往有一个独立的 recovery 分区通过特定按键组合或者串口命令进入能刷写系统分区、重置用户数据。原理和前面几种一样只是工具链更精简。选哪种取决于你的故障处在哪一层。引导器坏了就去 Live 介质只是忘了密码就走单用户云主机上没有物理接触就走控制台救援嵌入式设备刷坏了就走 recovery。判断错了入口后面的操作全是白费力气。1.2 “改 root”到底在改什么密码、权限还是账户本身这里必须先澄清一个高频误解系统认的是 UID不是用户名。/etc/passwd里每一行有七个字段第三个字段是 UID只要这个值是 0这个账户在系统眼里就是超级用户不管它叫 root、叫 admin 还是叫一个随机字符串。反过来你要是把真正的 root 那一行的 UID 从 0 改成 1000它就瞬间变成一个普通用户而另一个 UID 为 0 的账户会继承全部权限。理解了这一点再看“改 root”这件事就会发现有五种完全不同的操作操作类型具体动作典型触发场景改密码重设/etc/shadow第二字段的哈希密码遗忘、交接断档改登录状态去掉密码字段前的!、!!账户被误锁定改登录 shell把/sbin/nologin换回/bin/bash系统加固后无法登录改 UID/GID修正被篡改的第三、第四字段权限错乱、账户被改改授权配置修复/etc/sudoers或用户组sudo 报语法错误这五种操作在救援环境下的手法完全不同。改密码最简单passwd一条命令改登录状态要手工编辑 shadow 文件改 sudoers 必须用visudo -c校验否则一个语法错误就能让整个 sudo 体系瘫痪改 UID 则要考虑它名下所有文件的属主归属改完之后可能需要全盘chown。所以动手前先想清楚你面对的是哪一类问题不要一想到“root 有问题”就条件反射去改密码。1.3 为什么救援环境下能改 root而正常系统里改不了正常系统里改 root 密码需要先通过 PAM 认证——你得先证明自己是 root 或者有 sudo 权限。认证环节本身就是一道门进不去就改不了。救援环境做的事情是把这扇门整个绕过它不启动目标系统的 init不加载目标系统的 PAM 配置直接以另一个操作系统的身份去读写磁盘上的文件。你在救援 shell 里对/mnt/sysroot/etc/shadow做任何修改本质上和用另一台机器挂载这块硬盘改文件没有区别。这也解释了一个安全常识物理接触等于完全控制。任何能接触到机器的人只要能进引导器就能重置 root 密码。所以真正意义上的防护不在密码强度而在两件事——机房和机柜的物理管控以及磁盘加密。前者防止别人插 U 盘后者保证即便硬盘被拔走里面的数据也解不开。这两条是底线其他的加固手段都是在这个基础上叠加。2. 进入救援环境前的准备与风险判断我有一次印象很深的事故某公司一台跑着内部服务的机器启动失败值班的同事直接进单用户模式改了密码然后reboot结果系统在 fstab 检查那一步卡住因为真正的故障是数据盘掉了fstab 里那条挂载项找不到设备。密码改对了机器还是起不来白白多花了一个小时。这个教训很朴素救援环境的第一目标是搞清楚故障在哪而不是急着改你想改的那个东西。动手之前的准备工作比动手本身更重要。2.1 备份与现场信息采集清单进了救援 shell 之后第一件事不是敲passwd而是采集现场。我的习惯是按下面这个顺序过一遍全程只读不做任何修改# 1. 看清块设备布局 lsblk -f blkid # 2. 如果有 LVM确认卷组状态 pvs; vgs; lvs # 3. 如果有软 RAID确认阵列状态 cat /proc/mdstat # 4. 查看目标系统的分区表和挂载配置 fdisk -l cat /etc/fstab # 挂载后才有意义 # 5. 查看最近的系统日志定位上一次崩溃原因 journalctl -b -1 -p err --no-pagerlsblk -f这个命令值得单独说一句。它能一次性把设备名、文件系统类型、UUID、挂载点全列出来是判断“盘还在不在、分区认没认出来”的最快手段。如果目标分区在lsblk里根本看不到那说明问题在更底层——阵列没组装、LVM 没激活或者盘真的坏了这时候改 root 毫无意义。至于备份救援环境下能做的备份其实是“救急备份”不是完整备份。最实用的做法是把要改的那几个文件先复制一份cp -a /mnt/sysroot/etc/shadow /mnt/sysroot/etc/shadow.bak.$(date %Y%m%d) cp -a /mnt/sysroot/etc/passwd /mnt/sysroot/etc/passwd.bak.$(date %Y%m%d) cp -a /mnt/sysroot/etc/sudoers /mnt/sysroot/etc/sudoers.bak.$(date %Y%m%d)别小看这三个文件。我在社区里见过不止一次因为 shadow 格式写错、少了一个冒号导致整台机器所有账户全部无法登录的情况。有备份两分钟回滚没备份就得重新数冒号。注意修改任何配置文件之前先确认你改的是目标系统的文件而不是当前救援环境的文件。救援环境里也有/etc/shadow改错了地方一点用没有。判断方法很简单看路径前缀——如果你 chroot 进去了路径是/etc/shadow如果没 chroot路径应该是/mnt/sysroot/etc/shadow这种带挂载点的形式。2.2 不同故障场景对应的救援路径选择把常见场景和对应路径列成一张表出问题的时候可以直接对号入座故障现象推荐入口关键前置动作忘记 root 密码系统能正常启动到登录界面GRUB 单用户 /rd.break无GRUB 菜单都看不到Live 介质或云控制台救援确认启动顺序、确认介质可用卡在 emergency shell提示 fstab 挂载失败已进入紧急模式先注释 fstab 故障项再继续系统盘是 LVM救援环境看不到逻辑卷任意入口vgchange -ay激活卷组系统盘做了 LUKS 加密Live 介质cryptsetup luksOpen解密云主机 SSH 完全连不上控制台救援模式平台侧挂载系统盘为数据盘嵌入式设备反复重启recovery 分区确认按键组合或串口指令sudo 全线报错但 root 密码还在单用户模式用visudo -c定位语法行这张表里最容易被忽略的是 LVM 那一条。很多人进了救援环境lsblk只看到一块裸盘没有分区就以为盘坏了。实际上 LVM 的逻辑卷需要先激活才会出现设备节点默认情况下救援环境不一定自动激活。vgchange -ay这个命令看起来不起眼但它救过我不止一次。2.3 三个必须提前想到的坑只读挂载、SELinux、加密盘只读挂载。用rd.break进救援环境/sysroot默认是只读挂载的你直接passwd会报“无法写入”。必须先mount -o remount,rw /sysroot。用init/bin/bash的方式进来根分区同样是只读的得mount -o remount,rw /。这一步不做后面所有写操作全失败而且报错信息往往很含糊容易让人以为是权限问题。SELinux。这一条是重灾区。在启用 SELinux 的系统上你在救援环境里改/etc/shadow文件内容变了但文件的 SELinux 安全上下文没有跟着变因为救援环境可能根本没加载目标系统的策略下次开机 SELinux 一检查发现/etc/shadow的标签不对直接拒绝所有进程读取它结果是所有账户都登不进去连 root 都不行。解法是在 chroot 环境里创建一个标记文件让系统下次启动时自动重打标签touch /.autorelabel这个命令看起来莫名其妙但它是救命的一行。代价是重启会慢一些因为要遍历整个文件系统重新打标签。如果不幸忘了加也没关系进救援环境补上再重启就行只是多折腾一轮。加密盘。系统盘做了全盘加密的情况下救援环境挂载分区时会提示未知的文件系统类型。正确的姿势是先解密再挂载cryptsetup luksOpen /dev/vda2 cryptroot # 输入密码后会出现 /dev/mapper/cryptroot mount /dev/mapper/cryptroot /mnt/sysroot如果是 LVM on LUKS 的结构解密之后还要再vgchange -ay激活一次卷组才能看到逻辑卷。这个顺序不能反反了找不到设备。3. 实操在救援环境里重置 root 密码的完整流程前面铺垫了那么多现在进入正题。我把三种主流入口的完整流程都写一遍你可以根据自己的环境挑一条走。三条路径的目标是一致的拿到一个能写目标系统根分区的 shell改掉该改的东西然后干净地重启。3.1 路径一GRUB 参数注入最快适合物理机和可交互的虚拟机这是最常用的方式前提是能看到 GRUB 菜单。开机时按住 Shift 或者反复敲 Esc不同引导器行为不一样调出菜单后选中默认启动项按e进入编辑模式。找到以linux或者linux16开头的那一行这行末尾就是内核参数。常见的注入方式有两种方式 Ard.break。在行尾加一个空格写rd.break。这个参数让 initramfs 在挂载真正的根文件系统之前停下来给你一个临时的 shell。此时真正的根分区挂在/sysroot是只读的。# 进入后依次执行 mount -o remount,rw /sysroot chroot /sysroot passwd root # 输入两次新密码 touch /.autorelabel # SELinux 启用时必须执行 exit exit # 再 exit 一次会触发重启方式 Binit/bin/bash。这个更彻底直接跳过 init 系统。加在行尾后按 CtrlX 启动。mount -o remount,rw / passwd root touch /.autorelabel exec /sbin/init # 或者直接 reboot -f两种方式的区别在于rd.break停在 initramfs 阶段环境更干净但根分区路径是/sysrootinit/bin/bash停在真正的根文件系统上路径是/但很多服务没起来某些命令可能不可用。我个人更常用rd.break因为它的行为在不同发行版之间更一致。改完之后有个细节要注意passwd命令在某些系统上会提示“密码太简单”然后拒绝。如果你是在恢复生产环境没工夫折腾密码策略可以用passwd --stdin从标准输入喂密码或者临时改一下/etc/security/pwquality.conf。但我要提醒一句恢复之后记得把密码改成符合策略的别留下一个弱口令当后门。3.2 路径二Live 介质挂载 chroot最灵活适合引导器损坏或云主机Live 介质的流程更长但适用面最广。启动进 Live 系统后打开终端按下面的顺序走# 1. 找到目标系统盘 lsblk -f # 2. 如果根分区在 LVM 上先激活 vgchange -ay # 3. 如果根分区加密先解密 cryptsetup luksOpen /dev/vda2 cryptroot # 4. 挂载根分区 mkdir -p /mnt/sysroot mount /dev/mapper/vg0-root /mnt/sysroot # 5. 挂载 boot 分区UEFI 系统还要挂 EFI 分区 mount /dev/vda1 /mnt/sysroot/boot mount /dev/vda0 /mnt/sysroot/boot/efi # 6. 挂载虚拟文件系统这是 chroot 能正常工作的关键 for d in dev proc sys run; do mount --bind /$d /mnt/sysroot/$d done # 7. 切换根目录 chroot /mnt/sysroot /bin/bash第 6 步的四个mount --bind是新手的常见遗漏。不挂/proc和/syschroot 进去之后很多命令会报奇怪的错误比如passwd提示无法读取系统信息或者systemctl完全没反应。挂上之后环境才算完整。chroot 进去之后的操作就和在一台正常机器上一样了passwd root、编辑/etc/shadow、修复/etc/sudoers全部按正常路径来。完事之后退出 chroot逐层卸载再重启exit umount -R /mnt/sysroot rebootumount -R是递归卸载会把前面 bind 的那几个目录一起卸掉。如果提示 target is busy用lsof f -- /mnt/sysroot找出占用进程或者干脆umount -l懒卸载然后直接重启——反正是要重启的文件系统会在重启时重新检查。云主机的流程和这个基本一致区别在于系统盘是被平台挂载成一块额外的数据盘比如/dev/vdb你在救援系统的 SSH 里看到的是它而不是本地的/dev/vda。3.3 路径三单用户模式与紧急模式适合 systemd 系统systemd 体系的系统GRUB 里加single或者systemd.unitrescue.target能进到一个只启动基础服务的最小环境通常不需要输入密码就能拿到 root shell。如果加systemd.unitemergency.target环境更极端连根文件系统都是只读的需要手动 remount。这种方式的好处是环境接近真实系统systemctl、journalctl这些工具都能用排查问题方便。坏处是它依赖系统的 init 配置本身是好的——如果/etc/fstab写坏了导致根本进不去 rescue.target那就只能退回rd.break或者 Live 介质。另外提醒一点有些系统在 GRUB 上单独设置了引导密码防止别人随便编辑启动参数。这种情况下你连编辑界面都进不去只能走 Live 介质。这也是为什么我在第 1.3 节强调物理管控——引导密码只能挡住随手按两下的人挡不住真的想进去的人。3.4 改完后的验证动作别急着收工密码改完、重启之前有几个验证动作建议做一遍。在 chroot 环境里执行# 1. 检查 shadow 文件格式确认字段数量正确 awk -F: {print NF, $1} /etc/shadow | grep -v ^9 # 2. 检查 passwd 文件的 UID 字段 awk -F: $30 {print $1, $3} /etc/passwd # 3. 校验 sudoers 语法 visudo -c # 4. 确认关键文件权限 ls -l /etc/passwd /etc/shadow /etc/sudoers第 1 条命令的意思是shadow 文件的每一行应该有 9 个字段如果有哪一行不是 9 个说明格式被改坏了。这个检查能提前发现绝大多数“改完之后登不进去”的问题。第 2 条确认 UID 为 0 的账户有哪些如果出现了你不认识的账户名那就要警惕了——这可能是入侵留下的后门。第 4 条确认权限/etc/passwd应该是 644/etc/shadow应该是 000 或者 600/etc/sudoers应该是 440。权限不对的话认证系统会直接拒绝读取。4. 比改密码更复杂的几种变形情况密码遗忘只是最简单的一类。实际处理中我更常遇到的是账户被锁、shell 被改、权限被篡改这些情况处理起来要复杂得多也更容易出错。这一节把这几种变形情况逐个拆开。4.1 读懂 /etc/shadow 的九个字段要处理复杂的账户问题必须先能读懂 shadow 文件。每一行用冒号分隔成九个字段用户名:密码哈希:最后修改天数:最小间隔:最大间隔:警告天数:失效天数:保留字段第二个字段是重点它有几种特殊形态含义完全不同字段内容含义能否登录$6$xxxx...正常的 SHA-512 哈希密码正确就能登!或!!账户被锁定不能*从未设置过密码不能除非用密钥空两个冒号紧挨空密码能且不需要密码!$6$xxxx...有密码但被锁定不能这里有个很容易搞错的地方!!表示“账户从未设置过密码”而!前缀加在已有哈希前面表示“账户被锁定”。有些加固脚本会把所有系统账户的密码字段改成!!如果你不小心把一个需要登录的账户也改成了这个那它就彻底进不去了。恢复方法是在救援环境里把!前缀去掉或者直接重新设置密码。第三个字段也值得留意它是“密码最后修改时间”单位是从 1970-01-01 起算的天数。如果这个值是 0某些系统会认为密码已过期强制要求下次登录时修改。在救援环境里改密码时passwd通常会自动更新这个字段但如果你是手工编辑文件就得自己算天数否则可能出现“密码明明是对的但就是不让登”的怪现象。4.2 账户被 nologin、shell 被改、UID 被篡改的处理shell 被改成 nologin。这是系统加固的常见动作把没必要登录的服务账户的 shell 设成/sbin/nologin。问题是有时候会误伤把需要登录的管理账户也改了。表现是 SSH 能连上但立刻被踢出来提示“This account is currently not available”。救援环境下的修复很简单chroot /mnt/sysroot usermod -s /bin/bash root # 或者直接编辑 /etc/passwd把最后一字段改掉UID 被篡改。这是比较麻烦的一种。假设有人把 root 那一行的 UID 从 0 改成了 1000那 root 就变成了普通用户而系统里没有任何 UID 为 0 的账户结果是所有需要超级权限的操作全部失败但系统还能启动。修复的时候不只是改回 UID# 先把 UID 改回来 usermod -u 0 -o root # 然后把原本属于旧 UID 的文件属主一起修正 find / -xdev -uid 1000 -exec chown root:root {} \;-o参数是允许非唯一 UID因为可能已经有其他账户占用了 0。find那条命令要格外小心-xdev的作用是限制在同一个文件系统内避免遍历到挂载的网络盘或者临时文件系统上。不加这个参数在某些环境下会卡很久甚至改动到不该改的地方。账户被删除但文件还在。还有一种情况是/etc/passwd里 root 那一行整个没了但系统文件都还在。这种修复方式最直接——手工补回来root:x:0:0:root:/root:/bin/bashx表示密码在 shadow 里。补完之后再确认 shadow 里也有对应的行。这种操作看起来粗暴但确实有效前提是你知道正确的格式。4.3 sudoers 损坏导致全线瘫痪的修复/etc/sudoers是另一个高发故障点。它有个特点语法错误会导致整个 sudo 体系拒绝工作而且错误提示非常不友好往往只说“sudoers 文件第 N 行有语法错误”不说具体错在哪。更麻烦的是如果你只有 sudo 权限、没有 root 密码那 sudo 一坏就等于彻底失去权限。救援环境下的修复流程chroot /mnt/sysroot visudo -c # 先检查会明确指出出错的行号 # 根据提示修好那一行 visudo -c # 再检查直到显示 parsed OKvisudo -c是关键工具它只检查不修改能精确报出问题行。修好之后还要顺手检查一下/etc/sudoers.d/目录下的包含文件很多人只改了主文件忘了子目录里还有一份坏的。提示在救援环境里用visudo编辑时如果提示找不到编辑器可以先export EDITORvi。另外修复 sudoers 之后不要忘记检查它包含的组是否存在——如果 sudoers 里引用了某个组而那个组在/etc/group里被删了sudo 同样会报错。5. 常见问题与排查技巧实录这一节把我实际遇到过的问题整理成速查表附上排查思路。有些问题看一眼现象就能定位有些则需要一步步试。表格只是索引具体怎么判断后面还有展开。5.1 典型报错与处理速查现象大概率原因处理方式passwd提示无法写入根分区只读挂载mount -o remount,rw /sysrootchroot 后systemctl无响应虚拟文件系统没挂补mount --bind /proc /sys /run改完密码重启后所有账户都登不进SELinux 上下文错误救援环境里touch /.autorelabel救援环境看不到 LVM 逻辑卷卷组未激活vgchange -ay挂载分区提示未知文件系统分区加密cryptsetup luksOpen先解密卡在 emergency shellfstab 有无效挂载项注释掉故障行或加nofailsudo 报语法错误sudoers 有格式问题visudo -c定位行号密码正确但登录被拒密码过期或账户锁定检查 shadow 第三、第二字段重启后卡在A start job is running某个服务依赖的设备不存在救援环境下systemctl mask该服务改完 UID 后大量文件权限异常属主没跟着改find / -xdev -uid 旧UID -exec chown5.2 几个不写在文档里的经验经验一先看日志再动手。journalctl -b -1能看上一次启动的日志这一条能省掉大量猜测。我遇到过一次机器启动失败表面上像是密码问题看日志才发现是/var分区满了导致 systemd 无法启动关键服务。如果上来就改密码改完还是起不来白忙一场。经验二SELinux 的坑比你想象的多。除了改 shadow 要打标签改/etc/passwd、/etc/group、/etc/sudoers都有同样的风险。稳妥的做法是不管改哪个都在 chroot 里touch /.autorelabel。重启慢一点但总比开不了机强。如果系统用的是其他强制访问控制机制也要查一下有没有类似的重新标记流程。经验三别在救援环境里做计划外的操作。救援环境的目标是“让系统能正常启动并登录”不是“顺便优化一下配置”。我见过有人在救援环境里顺手升级了内核结果引导器配置没更新机器彻底起不来。所有非必要的改动等系统起来之后再说。经验四网络配置在救援环境里往往是坏的。安装介质启动的救援模式网络接口默认不启用需要手工dhclient或者配静态地址。如果你需要联网查资料或者下载工具先把这个搞定。但要注意救援环境下的网络配置不会保存到目标系统别在这里改/etc/resolv.conf然后以为生效了。经验五验证要用“冷启动”而不是reboot。有些问题在软重启时不会暴露比如某些硬件初始化顺序问题、某些固件的状态残留。改完 root 相关配置后如果条件允许做一次完全断电再上电的冷启动能暴露更多问题。这一点在嵌入式设备上尤其明显。经验六记录你做了什么。救援环境下的操作很容易记混尤其是同时处理多台机器的时候。我的习惯是在改之前先history -w保存一份或者干脆拿纸笔记下改动的文件路径。事后复盘、写事故报告、给同事交接都靠这个。6. 改完 root 之后该做的收尾工作很多人把“能登录了”当成终点其实那只是中点。一次 root 相关的故障处理完至少还有三件事要做确认改动没有引入新的隐患、搞清楚这次故障的根因、把防复发的手段补上。这三件事不做下次同样的故障还会再来一遍。6.1 第一时间做安全审计如果故障原因是“密码忘了”那没什么好说的改完就完事。但如果原因是“账户被锁”“UID 被改”“sudoers 被破坏”那就要认真想想是谁改的为什么改。这时候需要查的东西包括# 1. 最近的登录记录 last -n 50 lastb -n 50 # 失败的登录尝试 # 2. 账户文件的修改时间 stat /etc/passwd /etc/shadow /etc/sudoers # 3. 最近被修改过的系统文件 find /etc -type f -mtime -7 -ls # 4. 计划任务里有没有陌生条目 crontab -l ls -la /etc/cron.*第 2 条命令的stat输出里有个 Modify 时间如果这个时间和故障发生的时间对得上说明改动就是那次故障的直接原因。如果对不上反而更值得警惕——可能有人在更早的时候动了手脚只是现在才暴露。第 3 条命令扫的是/etc下最近七天被改过的文件。这个范围不要放大到整个根目录否则输出太多没法看。/etc是配置集中的地方异常改动大部分会落在这里。6.2 把“下次不用进救援环境”这件事安排上救援环境是最后手段用一次就说明前面的防线全失效了。处理完之后按性价比排序我建议至少做下面几件事配置一个带 sudo 权限的备用管理账户。这不是后门是冗余。root 密码只有一个人知道那个人休假了怎么办备用账户的密码交给两个人分别保管权限通过 sudoers 精细控制只开放必要命令。给/etc/fstab的关键挂载项加nofail。数据盘掉了不应该阻止系统启动。加了nofail之后设备不在就跳过系统照常起来只是那个挂载点空着事后修就行。确认引导器配置有备份。引导器配置被改坏是最难恢复的故障之一。定期把引导配置目录打包备份到别的地方出问题时直接还原。给系统盘做定期快照。云主机上这个几乎是免费的物理机上可以用文件系统快照。有了快照很多故障根本不需要救援环境直接回滚就行。把救援流程写成文档放在触手可及的地方。故障发生时人是慌的有文档和没文档效率差好几倍。文档里要写清楚这台机器的分区布局、是否加密、是否 LVM这些信息在紧急时刻根本来不及现查。6.3 关于“改 root”这件事的一个认知修正我在前面反复强调系统认的是 UID 而不是用户名这里再补一层root 这个身份本身也不是铁板一块。现代的权限体系里root 的权限可以被各种机制削弱——强制访问控制策略、能力capability划分、只读挂载、容器隔离都能让“UID 为 0”这个身份拿不到完整的控制权。反过来说一个精心配置的普通账户通过 sudo 和特定的能力授权实际能做的事情可能比一个被限制的 root 还多。所以当你遇到“root 登不进去”或者“root 权限不够”的问题时先别急着改密码。问自己三个问题这个系统有没有启用额外的访问控制是不是某个挂载点被设置成了只读是不是某个服务被单独的沙箱限制了这三个问题能解释掉相当一部分看起来像“root 坏了”的故障。最后分享一个我自己的习惯每次从救援环境里出来我都会在机器的/root下留一个rescue-notes.txt写上这次是什么时间、因为什么故障、进了哪种救援环境、改了哪些文件。这个文件不占地方但下次再出问题打开一看就知道历史情况。运维这件事很多时候不是靠聪明是靠记得住。