dracut:/#

或者伴随着 Timeout start of reboot 等错误信息，别慌张，这并非世界末日，而是系统在启动过程中遇到了无法自行逾越的障碍,转而向你求助的信号。

理解 dracut：它不是敌人，而是救星

我们需要端正一个认识。dracut 是一个用于构建 initramfs（初始内存文件系统）的工具集，在Linux系统启动时，内核会首先加载这个 initramfs 镜像，它是一个临时的根文件系统，里面包含了挂载真实根文件系统所必须的驱动、工具和脚本。

当系统无法找到或挂载真正的根分区时，它就会停在这个 initramfs 环境里，也就是我们看到的 dracut shell。dracut 的出现本身是一个保护机制，它阻止了一次注定失败的系统启动，并给了我们一个修复问题的机会。

探寻问题的根源：为什么我们会进入这里？

导致进入 dracut 救援模式的原因多种多样，但根据我的经验,最常见的有以下几条：

1. 根文件系统识别错误或丢失（最常见）：这是头号元凶，可能是 /etc/fstab 文件配置错误、磁盘UUID变更（尤其是在虚拟机克隆或磁盘调整后）、RAID阵列未正确组装、LVM卷组未激活或根分区文件系统损坏。
2. 内核模块缺失：initramfs 镜像中缺少了识别存储设备（如SCSI、SATA、NVMe控制器）所必须的驱动程序，这可能在更新内核后，新的 initramfs 未正确包含这些驱动时发生。
3. Initramfs 镜像损坏或过时：当前的 initramfs 镜像本身可能已损坏,或者它对应的内核版本与你正在启动的内核不匹配。
4. 硬件故障：存储设备本身出现物理故障或连接问题,导致系统根本无法读取磁盘。

动手修复：从 dracut shell 中一步步突围

我们来到了最关键的部分，请保持冷静,按照以下步骤进行排查和修复。

第一步：收集信息，诊断问题

在 dracut:/# 提示符下，我们首先需要弄清楚系统看到了什么,以及它为什么找不到根分区。

• 查看可用块设备：

  lsblk

  或者

  blkid

  这个命令会列出所有系统识别到的磁盘和分区，仔细观察，找到你认为是根分区（）的那个分区，它通常是 sda1、sda2、vda1、nvme0n1p1 这样的设备。

• 检查 LVM 状态（如果使用了LVM）：

  

  lvm pvs
  lvm vgs
  lvm lvs

  这些命令会显示物理卷、卷组和逻辑卷的状态，如果卷组没有激活，可以使用 vgchange -ay 来激活所有卷组。

• 尝试手动挂载根分区： 假设通过 lsblk 你发现 /dev/sda2 可能是你的根分区,尝试手动挂载它：

  mkdir /mnt/sysroot
  mount /dev/sda2 /mnt/sysroot

  • 如果挂载成功：恭喜！这证明根文件系统本身是好的，问题很可能出在 initramfs 镜像或者引导配置上,跳到第二步。
  • 如果挂载失败（例如提示 you must specify the filesystem type 或 wrong fs type）：说明文件系统可能损坏或者类型不匹配，可以尝试使用 fsck 修复：

    fsck -y /dev/sda2

    修复后再尝试挂载。

第二步：分析启动失败的根本原因

如果手动挂载成功,我们需要查看真实根文件系统中的一些关键文件。

• 检查 /etc/fstab：

  cat /mnt/sysroot/etc/fstab

  确认其中根分区的标识（UUID或设备名）是否与 blkid 显示的一致，如果不一致,这就是问题所在。

• 检查 /boot/grub2/grub.cfg：

  cat /mnt/sysroot/boot/grub2/grub.cfg | grep 'linux16\|linuxefi'

  查看启动项中 root= 参数指定的设备是否正确。

第三步：执行修复操作

根据上面的诊断结果,选择对应的修复方法。

• 情况A：修复 /etc/fstabfstab 文件错误,我们需要在救援模式下编辑它：

  vi /mnt/sysroot/etc/fstab

  将根分区的条目修正为正确的UUID或设备名，可以使用 blkid 命令获取正确的UUID。

• 情况B：重建 initramfs 镜像 这是解决驱动问题和镜像损坏的通用方法，我们需要 chroot 到真实的系统环境中操作。

  # 挂载必要的虚拟文件系统
  mount -t proc /proc /mnt/sysroot/proc
  mount -t sysfs /sys /mnt/sysroot/sys
  mount -o bind /dev /mnt/sysroot/dev
  mount -o bind /dev/pts /mnt/sysroot/dev/pts
  mount -t tmpfs /tmp /mnt/sysroot/tmp
  # 切换根环境
  chroot /mnt/sysroot /bin/bash
  # 确认当前内核版本
  uname -r
  # 重建当前内核的 initramfs
  dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
  # 如果上面的命令不知道内核版本，可以尝试强制重建
  dracut -f --regenerate-all

  完成后，输入 exit 退出 chroot 环境，然后执行 reboot 重启系统。

• 情况C：使用救援模式或安装介质 如果以上方法都无法解决，或者你无法在 dracut shell 中进行操作，那么使用 CentOS 安装光盘或USB驱动器进入“救援模式”是更强大的选择，救援模式会自动尝试查找并挂载你的根文件系统，并给你一个完整的shell环境,操作起来会更加方便。

如何防患于未然？

作为一名管理者,我深知预防远比补救重要。

1. 谨慎操作 /etc/fstab：在修改此文件前，务必备份，修改后，可以使用 mount -a 命令测试挂载是否正常,而无需重启。
2. 内核更新后留意：在执行 yum update 或 dnf update 更新内核后，系统通常会自动重建 initramfs，但偶尔会出现异常,更新后留意第一次重启过程是良好的习惯。
3. 备份引导分区和关键配置：定期备份 /boot 目录和 /etc/fstab 等关键配置文件。

面对 dracut 提示符，它更像是一次对你系统管理能力的考验，它所揭示的，往往是系统底层最核心的磁盘、文件系统和引导流程问题，通过冷静分析、逐项排查，绝大多数情况都是可以成功修复的，每一次成功从 dracut 中修复系统，你对 Linux 启动过程的理解都会更加深刻。