开机后进度条转了半天，屏幕上出现一行 dracut-initqueue[XXX]: timeout, still waiting for following devices，紧接着系统掉进紧急 shell，这是不少运维和桌面用户都遇到过的问题。本质上这是 initramfs（由 dracut 生成的早期用户空间）在等待根设备出现，但等到超时也没等到。与其反复重启碰运气，不如利用 dracut 提供的调试参数把问题一次性查清楚。
一、理解 initqueue 阶段的工作机制
dracut 生成的 initramfs 里有一个核心服务叫 initqueue，它负责在真正的根文件系统挂载之前，反复探测并等待根设备就绪。整个流程大致是：内核加载 initramfs，运行 /init，systemd 拉起 initqueue 服务，所有以 initqueue/ 结尾的脚本会被周期性执行，用来触发磁盘扫描、激活 LVM、组装 RAID、等待 multipath 路径收敛等。一旦根设备节点出现，initqueue 退出，系统继续切换到真实的根分区。
如果根设备一直没有出现，initqueue 默认会等待 rd.timeout（某些发行版为 180 秒或更长），超时后进入 dracut 紧急 shell，也就是你看到的 dracut-initqueue timeout 报错。理解这一点很关键：卡在这个提示并不是 dracfu 本身坏了，而是它没有能力找到你的根设备。原因无非几类——内核命令行的 root 参数写错、initramfs 缺少必要的驱动或模块、存储设备本身有硬件或配置问题。
进入紧急 shell 后先别慌，可以执行一些基础检查确认环境：用 cat /proc/cmdline 查看内核实际收到的启动参数，用 ls /dev/sd* 或 lsblk 看看磁盘到底识别出来没有。如果这里连磁盘都看不到，那问题多半出在驱动层面；如果磁盘在但设备名不对，那多半是 root 参数的问题。
二、使用 rd.shell 和 rd.debug 抓取详细日志
要深入排查，需要在内核启动参数里加上 dracut 的调试开关。编辑 GRUB 配置：开机到 GRUB 菜单时按 e 键，在 linux 或 linux16 那一行的末尾追加 rd.shell rd.debug log_buf_len=8M，然后按 Ctrl+X 启动。也可以直接编辑 /etc/default/grub 中的 GRUB_CMDLINE_LINUX，再执行 grub2-mkconfig 使其永久生效。
各参数的作用如下：rd.shell 保证超时后能进入 dracut 紧急 shell（而不是直接 panic 重启）；rd.debug 会打开 dracut 内所有 shell 脚本的 set -x 跟踪，把每一步执行细节写进日志；log_buf_len=8M 扩大内核日志缓冲区，避免调试信息被冲掉。需要注意的是，开启了 rd.debug 后日志会非常庞大，排查完记得把参数撤掉，否则每次开机都会在内存盘里留下大日志。
启动失败进入紧急 shell 后，日志保存在 /run/initramfs/rdsosreport.txt 中。这个文件汇总了内核消息、dracut 脚本追踪、块设备列表等关键信息，直接在里面搜索关键字往往能很快定位原因：
# 进入 dracut 紧急 shell 后执行 # 方法一：让 dracut 自己收集报告 > journalctl > exit # 退出时会提示，可执行 rdsosreport 生成报告 # 方法二：直接查看实时日志 grep -iE "timeout|waiting|failed|missing" /run/log/journal/*/*.journal # 查看内核识别到的块设备 cat /proc/partitions ls /sys/block
在日志中重点搜索这几类信息：第一类是 waiting for device 相关的行，它会明确告诉你系统在等哪个设备，比如 /dev/mapper/centos-root 或者某个 UUID；第二类是驱动加载失败的信息，比如 megaraid_sas、nvme 等模块缺失或加载报错；第三类是 multipath、LVM 相关的报错。找到具体报错后，就可以对照下面的常见原因逐项处理了。
三、initqueue 超时的常见原因与修复方法
第一种情况：root 参数与实际设备不匹配。比如系统重装或磁盘调整后 UUID 变了，而 GRUB 里还是旧 UUID。修复方法是进入紧急 shell 或用 Live CD 挂载根分区，用 blkid 查询所有分区的真实 UUID，再核对 /etc/fstab 和 GRUB 配置中的写法。注意有些用户把 rd.lvm.lv 写错或者干脆漏掉，导致 LVM 卷组没有被激活，根设备自然不会出现。正确的写法应该类似：
# GRUB linux 行示例，UUID 必须与 blkid 输出完全一致 linux16 /vmlinuz-... root=UUID=1a2b3c4d-xxxx ro \ rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet # 核对真实 UUID blkid /dev/sda2 # 在紧急 shell 中手动激活 LVM 验证 lvm vgscan lvm vgchange -ay
第二种情况：initramfs 缺少存储驱动。典型场景是系统盘从 SATA 迁到 NVMe、换了 RAID 卡，或者新内核更新后 initramfs 没有包含对应模块。这时可以在紧急 shell 中手动 modprobe nvme（或对应驱动）验证，如果能 modprobe 成功且磁盘随即出现，说明 initramfs 需要重建。重建时通过 --add-drivers 强制把模块打进去：
# 用 Live CD 或 chroot 环境执行 # 先挂载根分区并 chroot mount /dev/centos/root /mnt mount /dev/sda1 /mnt/boot chroot /mnt # 重建 initramfs 并强制加入指定驱动 dracut -f --add-drivers "megaraid_sas nvme" /boot/initramfs-$(uname -r).img $(uname -r) # 通用重生成（不带额外驱动） dracut -f -v
第三种情况：multipath 或 RDAC 等多路径环境配置异常。多路径设备初始化比较慢，默认超时可能不够，可以在内核参数中加大等待时间，例如 rd.timeout=600，同时确保 multipathd 服务正常、rd.multipath=default 参数存在。另外还有一类低级错误：initramfs 文件本身损坏或与内核版本不匹配，比如 /boot 分区空间满导致 initramfs 生成不完整。清理 /boot 后用 dracut -f 重新生成即可，重新生成前建议保留一份旧镜像以便回滚。
四、调试完成后收尾与预防措施
问题解决后，务必记得把 rd.shell rd.debug 从 GRUB 配置中移除。rd.debug 会产生海量 shell 跟踪输出，拖慢启动速度，还可能在内存有限的机器上带来额外压力。编辑 /etc/default/grub 恢复原有参数后，执行 grub2-mkconfig -o /boot/grub2/grub.cfg（Debian 系是 update-grub）刷新配置。如果修改过内核参数，一定要确认 /etc/fstab 中根分区的 UUID 也同步正确，否则下次更新内核生成新 GRUB 配置时问题可能复发。
作为预防，建议在更换存储硬件、升级 RAID 卡固件、大规模调整分区后，主动执行一次 dracut -f 重建 initramfs；为重要的生产机器保留一个旧版本的 initramfs 镜像和可用的 Live 救援介质；同时养成在 GRUB 菜单保留 rescue 条目的习惯。此外，日常可以在系统正常运行时执行 dracut --print-cmdline，它会输出 dracut 根据当前系统推断出的推荐启动参数，和 GRUB 中的实际参数做比对，能提前发现 root、LVM、多路径配置之间的不一致，把这类启动故障消灭在发生之前。
dracut-initqueueinitramfsrd.debug修改时间：2026-09-07 03:56:38