CentOS 7 Failed to mount /sysroot 排查修复-平芜编程栈

1. 一行报错背后的启动链条，先搞清楚 /sysroot 到底是谁

很多人第一次看到Failed to mount /sysroot的时候，第一反应是"我的硬盘挂了"或者"根分区被我删了"。说实话，我第一次遇到是在一台跑了两年的老服务器上，只是往机箱里加了一块直通盘，重启之后就再也没起来。当时我也慌，因为上面跑着数据库。但等我把这条链条捋清楚之后，发现大部分情况根本没那么严重，/sysroot挂不上有相当比例只是引导参数和实际设备对不上了。

先讲清楚/sysroot是个什么东西。它不是你的根分区本身，而是内核启动早期阶段临时使用的一个挂载点名字。CentOS 7 的启动分两段走：第一段是 BIOS/UEFI 把控制权交给 GRUB，GRUB 加载内核和 initramfs（一个压缩的微型根文件系统）；第二段是内核跑 initramfs 里的代码，这段代码只做一件事——找到真正的根分区，把它挂到/sysroot，然后把系统切过去。所以Failed to mount /sysroot的含义非常精确：initramfs 阶段没能把真正的根分区挂起来。它既可能是"找不到设备"，也可能是"找到了但挂不上"。

1.1 initramfs 里的 dracut 干了哪些活

CentOS 7 的 initramfs 是 dracut 生成的，它做的事情按顺序大概是：加载内核模块（存储控制器、LVM、加密、网络等）→ 解析内核命令行里的root=参数 → 等待设备出现（有个超时，默认跟rootdelay有关）→ 激活 LVM/加密层 → 找到目标块设备 → 调用mount挂到/sysroot→ 检查根分区上是否有 init → 切根并启动 systemd。

这里面每一步都可能出问题，但报出来的错误经常长得一模一样。比如驱动没加载和设备 UUID 写错了，最终都是那一行Failed to mount /sysroot。所以光盯着这行字是没用的，必须往上翻，看它前一屏打印了什么。

1.2 报错文本和真实根因的对照

我整理了一张表，是我这些年实际遇到过的情况，能覆盖八成场景：

报错前一屏的提示	大概率根因
`Warning: /dev/disk/by-uuid/xxxx does not exist`	UUID 变了，或分区表被改动
`dracut-initqueue timeout`反复出现	存储控制器驱动没进 initramfs
`Cannot activate LVs in VG xxx`	LVM 卷组没被激活，`rd.lvm.lv`参数丢失
`mount: wrong fs type, bad option, bad superblock`	文件系统损坏，或 fstab/参数写错类型
`Failed to mount /sysroot`前一片空白	initramfs 本身损坏或被截断
卡在`A start job is running for ...`然后超时	加密卷口令不对或 key 文件丢失

看完这张表你就能理解一件事：排查方向必须从"上一屏"反推，而不是从报错本身猜。这也是为什么我在下面第二节里要先讲信息采集，而不是直接给你救援模式的命令。

补一句容易被忽略的：CentOS 7 用的是initramfs-<内核版本>.img，存放在/boot下。而/boot本身在绝大多数部署里是一个独立的普通分区（ext4 或 xfs），并且是用设备路径或者 UUID写进 GRUB 的。如果你在扩容时动了分区顺序，比如把原来 sda2 上的 /boot 变成了 sda3，GRUB 可能连内核都找不到——那种情况根本看不到Failed to mount /sysroot，而是直接进 GRUB 救援提示符。能走到/sysroot这一步，说明内核和 initramfs 至少是加载成功的，这已经是个好消息了。

2. 动手之前，先把现场信息收集齐

我见过太多人一看到报错就顺手拿 U 盘刷系统、或者直接fsck一通乱按，最后把本来能救的数据搞没了。这个习惯非常危险。根分区挂不上这类问题，信息采集的成本远低于误操作的成本。这一节讲的都是不需要拆机、不需要进救援模式、在报错现场就能做完的事。

2.1 为什么"上一屏"比报错本身更有价值

CentOS 7 的 dracut 阶段输出很密集，很多人开机时看不到几行就一闪而过了。如果你用的是物理机接显示器，可以在 GRUB 菜单出现时按e进入编辑模式，找到以linux16或linuxefi开头的那一行，行尾追加rd.shell，然后按Ctrl+X启动。这样一旦挂载失败，dracut 不会傻等超时，而是直接掉进一个极简的 shell（就是dracut:/#那种提示符），你就能从容地看日志、敲命令了。

注意区分rd.shell和rd.break：

rd.shell：只有出错时才给你 shell，正常启动不受影响，适合排查挂载失败。
rd.break：可以指定rd.break=pre-mount、rd.break=mount、rd.break=pre-pivot，让你在指定的那一步之前强行中断。想研究挂载过程就加rd.break=mount。

这两个参数是临时生效的，重启就没了，不会污染配置，可以放心用。

进到 dracut shell 之后，按这个顺序看：

cat /proc/cmdline # 看内核实际收到的 root= 是什么 ls /dev/disk/by-uuid/ # 看磁盘上真实存在的 UUID 有哪些 blkid # 看每个块设备的类型和 UUID ls /dev/mapper/ # 看 LVM 逻辑卷有没有被激活 dmesg | tail -50 # 看内核认到了哪些盘、有没有 IO 错误

cat /proc/cmdline这一步我强烈建议放在第一位。很多事故的原因就藏在这里——GRUB 传过去的root=UUID=xxx，和blkid列出来的实际 UUID 对不上，一眼就能看出来。

2.2 rdsosreport：dracut 自动生成的现场快照

dracut 在启动失败时会自动把一大堆诊断信息写进/run/initramfs/rdsosreport.txt。这个文件非常全面，包含/proc/cmdline、blkid、dmsetup、lvm状态、内核日志节选等等，基本上你要的东西它都替你收集好了。

在 dracut shell 里把它导出到 U 盘（先插上 U 盘）：

mkdir -p /mnt/usb mount /dev/sdb1 /mnt/usb # 设备名以实际为准 cp /run/initramfs/rdsosreport.txt /mnt/usb/ umount /mnt/usb

注意：dracut 阶段的 shell 功能非常有限，只有 busybox 提供的那点命令，vi也不一定有。别指望在里面做复杂操作，收集完信息就去走救援模式。

2.3 用 rd.break 精确定位卡在哪一步

如果你已经确认设备存在、UUID 也对，但就是挂不上，那就要看是哪个阶段断的。加rd.break=mount进 shell 后，手工执行挂载试试：

mkdir -p /tmp/root mount -t xfs /dev/mapper/centos-root /tmp/root

这一步能直接暴露真实错误。比如返回structure needs cleaning，那基本确定是 xfs 日志需要修复；返回unknown filesystem type，那就是驱动或文件系统模块没进 initramfs。手工挂载一次，比看十屏日志都有用。

顺便说一句，如果根分区是 xfs，mount失败时它经常不会给出很明确的提示，你需要结合dmesg | grep -i xfs来看。ext4 的报错相对啰嗦一些，反而更好判断。

3. 从安装盘进救援模式，把真实系统挂起来

信息收集完，下一步就是救援。这里有个前提：你手上得有一张跟系统大版本匹配的 CentOS 7 安装镜像（7.9 的 ISO 可以救援所有 7.x 系统，向下兼容没问题）。U 盘刻录用 Rufus、balenaEtcher 或者直接dd都行，UEFI 机器记得选 UEFI 方式启动，否则可能识别不到硬盘上的 ESP 分区。

3.1 Troubleshooting 菜单里该选哪一项

启动安装盘后出现的第一个菜单，不要选 Install，要看下面的选项。CentOS 7 的安装镜像提供了：

Rescue a CentOS Linux system：这就是我们要的，它会自动探测硬盘上的系统并挂到/mnt/sysimage。
Run a memory test：跟本问题无关。
Boot from local drive：绕过镜像从本地盘启动，有时候 GRUB 配置没坏只是参数错的场景可以用它。

选救援之后会问你三个选项，含义分别是：

Continue：把探测到的系统挂载到/mnt/sysimage，读读写模式。
Read-only mount：只读挂载，纯看数据用，不会改动。
Skip to shell：什么都不挂，直接给你一个 shell。

我的习惯是：只要打算修东西，就先选Skip to shell。原因很简单，自动挂载有它自己的判断逻辑，遇到我们这种"根分区挂不上"的场景，它经常挂错或者挂不全，尤其是 LVM 上有多个逻辑卷的时候。手工挂载虽然多敲几条命令，但每一步都是可控的。

3.2 LVM、加密、软 RAID 上的根分区怎么手工激活

这是救援阶段最容易卡住的地方。顺序不能乱：

# 1. 先让内核重新扫描分区表 partprobe # 或 partx -u /dev/sda # 2. 如果是软 RAID mdadm --assemble --scan # 3. 激活 LVM vgscan vgchange -ay lvs # 确认逻辑卷都出来了 # 4. 如果是 LUKS 加密卷 cryptsetup luksOpen /dev/mapper/centos-root cryptroot # 按需

vgchange -ay这一步是重头戏，很多人救援失败都是因为忘了它。LVM 卷组在你没显式激活之前，/dev/mapper/下是空的，mount自然找不到东西。执行完lvs看到列表，再往下走。

提示：如果vgscan报Couldn't find device with uuid xxx，说明卷组的物理卷少了一块，这种情况多半是硬盘没被认到（接触不良、控制器问题、或者盘真坏了）。别急着vgreduce --removemissing，那会直接丢掉缺失盘的元数据。先把硬件问题查清楚。

3.3 chroot 前后各要注意什么

挂好根分区后：

mkdir -p /mnt/sysroot mount /dev/mapper/centos-root /mnt/sysroot # /boot 单独分区的话也要挂 mount /dev/sda2 /mnt/sysroot/boot # UEFI 机器还要挂 ESP mount /dev/sda1 /mnt/sysroot/boot/efi # 绑定必要的虚拟文件系统 mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys mount --bind /run /mnt/sysroot/run chroot /mnt/sysroot

为什么要 bind 这几个目录？因为dracut、grub2-mkconfig这些工具在运行时会去读/proc、/sys里的硬件信息（比如探测磁盘布局、判断是不是 UEFI），不挂的话它们要么报错，要么生成一个不完整的配置——后者更坑，你以为修好了，重启还是起不来。

chroot 之后第一件事，先mount -a看看/etc/fstab有没有报错，再做别的。这一步能顺手把 fstab 里的问题暴露出来。

4. 五类高频根因的定位与修复

到了这一步，我们已经能自由进出真实系统了，接下来就是对症下药。我把这些年遇到的情况归成五类，基本能覆盖绝大多数场景。

4.1 UUID 漂移与设备名错位

典型场景：改过分区表、克隆过磁盘、虚拟机磁盘被重新挂载、RAID 卡重建后盘序变了。

现象：dmesg 里提示does not exist，或者/proc/cmdline里的 UUID 和blkid输出不一致。

判断方法：

blkid | grep -E 'xfs|ext4' cat /etc/fstab cat /boot/grub2/grub.cfg | grep -o 'root=UUID=[^ ]*'

三处输出的 UUID 应该一致。只要有一处不同，那就是它了。

修复：把/etc/fstab和 GRUB 配置里的 UUID 改成blkid报出来的真实值，或者反过来——如果你希望保持原 UUID 不变，那就要查清楚为什么设备 UUID 会变。这里插一句：UUID 是写在文件系统超级块里的，单纯改分区表不会改变 UUID。UUID 变了通常意味着文件系统被重新格式化了，或者你挂载的是另一个分区。这一点很关键，别搞反了因果。

顺手提一下，虚拟机克隆场景特别容易踩这个坑。克隆出来的机器，网卡 MAC 变了，磁盘 UUID 理论上不变，但如果克隆时做了"重新初始化"，UUID 就会全部变掉。批量部署的时候建议用脚本统一检查一遍。

4.2 文件系统损坏：xfs_repair 和 fsck 该怎么选

典型场景：断电、宿主机强制关机、存储链路抖动。

判断方法：手工mount时报structure needs cleaning（xfs）或bad superblock（ext4）。

xfs 的处理：

xfs_repair -n /dev/mapper/centos-root # 先干跑，只看不改 xfs_repair /dev/mapper/centos-root # 确认后再真修

如果日志区损坏严重，会提示需要-L清日志：

xfs_repair -L /dev/mapper/centos-root

注意：-L会丢弃 XFS 日志，可能造成文件丢失或目录结构异常。这是最后手段，执行之前一定要确认数据有备份，或者至少先把盘做成镜像再操作。

ext4 的处理：

fsck.ext4 -f /dev/sda2

遇到"要不停按 y"的情况，用-y自动确认。但要注意，fsck必须在卸载状态下执行，如果在救援模式里已经挂上了，先umount再修，否则会二次损坏。

4.3 LVM 逻辑卷路径写在 GRUB 里，但没被激活

典型场景：根分区在 LVM 上，手动改过 GRUB 参数，或者从别的系统复制过 grub.cfg。

现象：GRUB 命令行里有root=/dev/mapper/centos-root，但 dracut 阶段/dev/mapper/下面是空的。

根因：dracut 需要靠内核命令行里的rd.lvm.lv=centos/root才能知道去激活哪个逻辑卷。如果写成/dev/mapper/centos-root，而且没有rd.lvm.lv，某些情况下 dracut 就找不到。

修复：把 GRUB 里的内核行改成规范写法：

root=/dev/mapper/centos-root rd.lvm.lv=centos/root rd.lvm.lv=centos/swap

然后在 chroot 里执行：

grub2-mkconfig -o /boot/grub2/grub.cfg

再确认一下/etc/default/grub里的GRUB_CMDLINE_LINUX，把你手工加的rd.lvm.lv写进去，否则下次grub2-mkconfig一跑又被覆盖掉了。这个"改了但没落盘"的坑我踩过两次，第二次之后我就养成了习惯——任何内核参数只改/etc/default/grub，绝不在 grub.cfg 里直接编辑。

4.4 存储控制器驱动没进 initramfs

典型场景：换了阵列卡、把系统盘从 SATA 挪到 NVMe、虚拟化平台换了磁盘控制器类型（比如从 IDE 换到 virtio）。

现象：dmesg 里根本看不到目标磁盘，ls /dev/disk/by-uuid/是空的或者只有安装盘。

判断方法：在 dracut shell 里lsmod，看对应驱动（比如megaraid_sas、mpt3sas、nvme、virtio_blk）有没有加载。

修复：在 chroot 环境里，把驱动加进 dracut 配置：

echo 'add_drivers+=" mpt3sas megaraid_sas "' > /etc/dracut.conf.d/storage.conf dracut -f --regenerate-all

然后验证驱动真的进去了，这点非常重要：

lsinitrd /boot/initramfs-$(uname -r).img | grep mpt3sas

有输出才算成功。没有输出就是白干，八成是模块名写错了，或者模块在当前内核里根本不存在。

4.5 内核升级后 initramfs 版本对不上

典型场景：yum update升级了内核，但/boot空间不足导致 initramfs 生成失败；或者手动删过旧内核。

现象：GRUB 菜单里选的那个内核，对应的 initramfs 文件不存在、大小为 0、或者被截断。

判断方法：

ls -lh /boot/ df -h /boot

正常的initramfs-xxx.img一般有十几到几十 MB，如果只有几百字节或者 KB 级，那就是生成失败了。

修复：先腾出/boot空间（删掉确定不用的旧内核文件），然后：

dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

/boot空间不足是个特别经典的坑。CentOS 7 默认给/boot就 200MB 或者 500MB，装几个内核就满了，而 yum 更新时如果 initramfs 写不进去，它不一定报错中断，你重启之后才发现起不来。所以我现在的习惯是，/boot一律给到 1GB 以上，图个心安。

5. 重建 initramfs 与引导配置的正确姿势

前面几节讲的修复动作，最后都要落到"重新生成 initramfs"和"重新生成 GRUB 配置"这两个操作上。这两个命令看着简单，但参数写错、路径搞混的情况非常多，值得单独拎出来讲。

5.1 dracut 的几个常用参数和它的脾气

dracut 的基本用法：

dracut -f # 用当前内核的默认参数重建 dracut -f /boot/initramfs-3.10.0-1160.el7.x86_64.img 3.10.0-1160.el7.x86_64

几个参数的含义：

-f：强制覆盖已有文件。不加它，dracut 会问你，脚本里跑就很烦。
--regenerate-all：给所有已安装内核都重建一遍。用它之前先确认/boot空间够。
--add-drivers "xxx"：临时加驱动，但我建议还是写进配置文件，不然下次再跑一次 dracut 就丢了。

配置文件放/etc/dracut.conf.d/下，随便起个名字：

# /etc/dracut.conf.d/90-storage.conf add_drivers+=" mpt3sas " force_drivers+=" mpt3sas "

add_drivers是把模块塞进 initramfs，force_drivers是额外保证它在早期就被加载。如果你的根分区依赖某个驱动，两个都写上最保险。

dracut 有个"脾气"要注意：它会根据当前系统的实际布局自动决定要包含哪些模块和工具。如果你是在救援环境里 chroot 过去跑 dracut，而/proc、/sys没 bind 好，或者hostonly模式判断失误，生成的 initramfs 可能缺东西。所以：

# 检查一下 hostonly 配置 grep -r hostonly /etc/dracut.conf /etc/dracut.conf.d/ 2>/dev/null

如果是通用镜像（要往多台机器部署），建议关掉 hostonly：hostonly="no"。代价是 initramfs 变大，好处是兼容性好。

5.2 grub2-mkconfig 的两个路径，千万别搞混

这是我最想强调的一点。BIOS 和 UEFI 机器的输出路径不一样：

启动方式	输出路径
BIOS (Legacy)	`/boot/grub2/grub.cfg`
UEFI	`/boot/efi/EFI/centos/grub.cfg`

在 UEFI 机器上写成了 BIOS 路径，命令不报错，但重启之后完全不生效，因为固件读的是 ESP 里那份。这个坑我踩过一次，改了半小时参数，重启发现跟没改一样，后来才反应过来。

保险的做法是两个都生成：

grub2-mkconfig -o /boot/grub2/grub.cfg grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

另外，grub2-mkconfig是从/etc/default/grub和/etc/grub.d/下的脚本读配置的。所以你要改内核参数，改/etc/default/grub里的GRUB_CMDLINE_LINUX，然后再跑 mkconfig。直接编辑 grub.cfg 是没用的，下次 mkconfig 一跑就全被覆盖。

引导程序本身如果坏了（比如重装过 Windows），还需要重装：

# BIOS grub2-install /dev/sda # UEFI grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=centos

5.3 重启之前的自查清单

修完别急着重启，先在 chroot 里把这几项过一遍，能省掉很多"重启一次白折腾一次"的时间：

/etc/fstab里所有 UUID 都能在blkid里找到；
ls -lh /boot/initramfs-*.img大小正常；
lsinitrd里能看到关键驱动；
/etc/default/grub里的参数和你预期一致；
两份 grub.cfg（如果适用）的修改时间都是刚刚；
如果是 ext4 根分区，别忘了检查/etc/fstab里最后一位（0 0还是0 1），把根分区设成1让开机自检。

还有一条经验：改动过根分区之后，第一次启动时 SELinux 可能会因为标签错乱而拒绝服务，表现为能进系统但很多服务起不来。如果你怀疑是这个问题，在 chroot 里执行：

touch /.autorelabel

然后重启，系统会自动做一次全盘 relabel。这个过程可能比较久（取决于文件数量），但能一次性解决标签问题。别在中途强制断电。

6. 折腾过几次之后，我固定下来的几个防复发习惯

前面讲的都是"出事了怎么修"。但说实话，这类问题修起来一小时，出事前花五分钟就能避免。所以最后分享几个我现在雷打不动的操作习惯，都是被实际事故教育出来的。

6.1 动分区表之前，先做三件事

我现在的动作顺序是固定的：

第一，记录现场。在改动之前，把这三样东西存下来：

blkid > /root/disk-info-$(date +%F).txt fdisk -l >> /root/disk-info-$(date +%F).txt lsblk -f >> /root/disk-info-$(date +%F).txt cat /etc/fstab >> /root/disk-info-$(date +%F).txt cat /proc/cmdline >> /root/disk-info-$(date +%F).txt

这几个文件加起来不到 10KB，但出事的时候价值连城。特别是blkid的输出，能让你一眼看出 UUID 有没有变。

第二，把这份记录拷到机器之外。放在本机根目录上是没用的——根分区都挂不上了，你怎么读它。U 盘、另一台机器、或者至少别放在同一块盘上。

第三，加盘、改阵列、换控制器这类操作，尽量在业务低峰期做，并且预留回滚时间。我见过太多"我就插一块盘，五分钟的事"最后变成两小时停机的例子。

6.2 内核不要只留一个

yum update之后，系统里会有多个内核版本。很多清理脚本或者"优化"教程会建议你删掉旧内核省空间，我建议至少保留两个能用内核，而且确认第二个真的能启动。

判断方法很简单：把 GRUB 默认启动项临时改成旧内核，重启验证一次。确认没问题再改回来。这样一旦新内核的 initramfs 有问题，你还能从 GRUB 菜单里选旧内核进去修——这比翻安装盘救援快太多了，几分钟就能搞定。

顺手把/boot分区划大一点，1GB 起步。这块空间现在看着浪费，出事的时候都是它救的场。

6.3 手机里存一份排错流程

最后这个是纯个人习惯：我在手机备忘录里存了一份极简排错流程，就十来行，包含：

出现Failed to mount /sysroot时，第一件事是加rd.shell看现场；
救援模式下 LVM 一定要vgchange -ay；
xfs_repair -L是最后手段；
UEFI 机器 grub.cfg 在 ESP 里；
改参数只改/etc/default/grub。

理由很实际：我们大多数时候遇到这种问题，是在凌晨、在机房、在只有手机能上网的环境里。这时候脑子是不清醒的，能有个清单照着走，比临时回忆靠谱得多。

这套东西说出来都很简单，但每一条背后都有一次真实的翻车。从一个"看到报错就重装系统"的新手，到现在能十分钟定位根因，中间隔的就是这些细节。你要是正好卡在Failed to mount /sysroot这一步，按第二节到第五节的顺序走一遍，大概率能在半小时内把机器救回来。

CentOS 7 Failed to mount /sysroot 排查修复