开机停在 dracut 紧急 shell，先确认哪一层出了问题

当 CentOS 7 开机后进入 dracut emergency shell，一般会看到类似 Entering emergency mode. Exit the shell to continue. 的提示，同时根文件系统无法挂载，系统停留在 initramfs 阶段的 shell 中。此时输入 journalctl -xb 可以查看启动日志，但多数情况下日志量较大，更快的做法是先在提示符下执行 ls /dev/sd* 或 blkid，确认内核是否能识别到硬盘和分区。若设备列表缺失或分区无 UUID，说明问题出在存储设备的识别或驱动加载阶段，而不是文件系统本身损坏。

当 CentOS 7 开机后进入 dracut emergency shell，一般会看到类似 `Entering emergency mode. Exit the shell to continue.` 的提示，同时根文件系统无法挂载，系统停留在 initramfs 阶段的 shell 中。此时输入 `journalctl -xb` 可以查看启动日志，但多数情况下日志量较大，更快的做法是先在提示符下执行 `ls /dev/sd*` 或 `blkid`，确认内核是否能识别到硬盘和分区。若设备列表缺失或分区无 UUID，说明问题出在存储设备的识别或驱动加载阶段，而不是文件系统本身损坏。

这类故障最常见的原因是 `/etc/fstab` 中的分区 UUID 与实际不符，或系统根分区对应的磁盘设备在启动时未被正确识别。例如，新增或更换硬盘后，旧 UUID 失效；主板开启了 RAID 模式而系统内核未包含对应驱动；也有部分场景是 initramfs 镜像损坏或缺失必要模块。排查时首先要确认是否近期改动过分区表、BIOS 设置或内核参数，这些改动通常会直接导致根设备无法挂载，从而触发 dracut 进入紧急 shell。

这一步的目的是先把故障范围缩小。如果 blkid 能列出所有分区，那说明磁盘和驱动基本没问题，重点可以放在 fstab 或内核参数上；如果列表里连硬盘都没有，就要考虑 BIOS 里的硬盘模式、SATA 线缆或者内核里有没有对应驱动。

一般来说是这几个原因之一

这类故障最常见的原因是 /etc/fstab 中的分区 UUID 与实际不符，或系统根分区对应的磁盘设备在启动时未被正确识别。例如，新增或更换硬盘后，旧 UUID 失效；主板开启了 RAID 模式而系统内核未包含对应驱动；也有部分场景是 initramfs 镜像损坏或缺失必要模块。排查时首先要确认是否近期改动过分区表、BIOS 设置或内核参数，这些改动通常会直接导致根设备无法挂载，从而触发 dracut 进入紧急 shell。

如果你记得最近动过磁盘分区、换过硬盘、或者在 BIOS 里改过 SATA 模式，那大概率和这些改动有关。另外，也可能是系统更新后 initramfs 没有重新生成，导致内核模块和实际硬件不匹配。

在紧急 shell 里先做三件事

第一，执行 cat /proc/cmdline，看看内核启动参数里 root= 指向的是设备路径还是 UUID。第二，用 blkid 列出当前可用的分区和 UUID，对照一下手上的记录。第三，如果根文件系统没有被挂载，可以尝试 mount /dev/sda1 /mnt，把原根分区挂到临时目录，然后直接读里面的 etc/fstab。注意这里的 /dev/sda1 只是示例，实际要用 blkid 或 lsblk 确认的设备名。

如果挂载时报错，提示文件系统损坏，可以先用 fsck -y /dev/sda1 修复。如果设备根本不存在，就需要回到 BIOS 检查存储模式，或者在启动参数里加载额外的驱动模块。

如果确实是 fstab 的 UUID 不对，这样改

假设你通过挂载原分区后，发现 /mnt/etc/fstab 里写的根分区 UUID 和 blkid /dev/sda1 得到的 UUID 不一样，那么最直接的修复就是在紧急 shell 里重新挂载根分区并 chroot 进去改 fstab。先执行 mount /dev/sda1 /sysroot，成功后再用 chroot /sysroot 进入原系统。进入后先备份 fstab：cp /etc/fstab /etc/fstab.bak，然后编辑 /etc/fstab，把根分区的 UUID 改成 blkid /dev/sda1 输出的实际值。如果根分区是 LVM 逻辑卷，就改成类似 /dev/mapper/centos-root 的设备路径，同时确认内核参数里有正确的 rd.lvm.lv。

编辑完以后，建议先执行 reboot -f 重启。注意：如果之前用 chroot 修改过，重启前最好先退出 chroot 并卸载挂载点，防止文件系统缓存没有完全落盘。退出方法是在 chroot 环境里执行 exit，再执行 umount /sysroot。

内核参数漏了 rd.lvm.lv 时，可以这样临时验证

有时候 fstab 并没有错，而是内核启动参数里的 root= 指向不明确，或者缺少 LVM 相关的激活参数。此时可以先在紧急 shell 里执行 reboot 重启，然后在 GRUB 菜单界面按 e 编辑启动项，在 linux16 或 linuxefi 行末追加 rd.debug 和 rd.shell，同时检查 root= 参数是否指向正确的设备或 UUID。如果根分区是 LVM，则需确保有 rd.lvm.lv=系统卷组/根逻辑卷 的参数。确认无误后按 Ctrl+x 启动，系统可能再次进入 shell，但此时可手动执行 vgchange -ay 激活卷组，再挂载根分区完成修复。此操作只影响本次启动，不会永久改变 GRUB 配置。

这个办法适合临时验证，如果通过这种方式能启动，说明问题大概率出在 GRUB 配置或 initramfs 生成时的参数上。之后需要持久化修改时，可以在系统内重新生成 GRUB 配置，或者更新 initramfs。但现在系统都进不去，所以先用临时参数把系统拉起来再说。

修复前先记住这几个风险边界

修复过程中需要注意几个边界：紧急 shell 中执行 fsck 只适用于 ext3/ext4 或 xfs 等默认文件系统，如果根分区是 btrfs，应先挂载后再用 btrfs check 处理，直接 fsck 可能加剧损坏。chroot 后修改 /etc/fstab 务必先备份原文件。另外，若硬盘设备名为 /dev/sda 但系统实际使用 NVMe 或 virtio 设备，路径会不同，应使用 blkid 或 lsblk 确认，不要盲目依赖 sda。最后，如果上述操作后仍无法启动，建议制作 CentOS 7 安装 U 盘，进入救援模式收集 rdsosreport.txt 日志，再寻求进一步支持，避免反复强制关机导致数据丢失。

最后一条建议很重要：即使你在紧急 shell 里能执行一些命令，也不要把这里当作正常的修复环境。每一次强制重启都可能带来文件系统元数据的额外风险。如果数据重要，优先考虑备份或镜像磁盘再做修改。