initramfs缺失存储驱动或root参数错误是waiting for root device主因；需检查驱动加载、add_drivers配置、rd.debug调试、root=匹配、LVM/LUKS参数及udev触发。
工具（如 dosfstools）写入
检查 fstab 与 kernel cmdline 的 root= 是否一致
很多人以为只要 /etc/fstab 写对就行，但 initramfs 阶段只认 kernel 命令行里的 root= 参数。如果 fstab 里是 UUID，而 grub.cfg 里写的是 LABEL，或反过来，就会因找不到设备卡住 —— 尤其当系统曾用过 systemd-boot 或手动编辑过 GRUB 配置后容易出错。
实操建议：
- 运行
cat /proc/cmdline查看当前实际传给内核的参数，重点核对root=和rd.luks.uuid=（如有加密）是否拼写正确、有无多余空格 - 对比
findmnt -D /输出的 UUID/LABEL 与 cmdline 中的值是否完全一致（区分大小写，短横线位置） - GRUB 用户检查
/boot/grub2/grub.cfg（RHEL/centos）或/boot/grub/grub.cfg（debian/Arch），确认linux行中的root=是最新生成的 - Arch 用户若用
grub-mkconfig，确保/etc/default/grub中GRUB_PRELOAD_MODULES包含part_gpt或part_msdos，否则无法解析分区表
加密卷或 LVM 场景下 missing rd.lvm.lv 或 rd.luks.name
如果 root 在 LVM 逻辑卷或 LUKS 加密容器中，仅靠 root=UUID=xxx 不够。initramfs 必须提前激活卷组、解密设备，这需要显式传递参数，否则它连“根设备在哪”都不知道，自然卡死。
实操建议：
- LVM 场景必须加
rd.lvm.lv=（如/ rd.lvm.lv=centos/root），多个 LV 用空格分隔 - LUKS 场景必须同时提供
rd.luks.name=UUID=xxx:luks-xxx和rd.luks.uuid=xxx，且luks-xxx需与/etc/crypttab中的映射名一致 - dracut 用户检查
/etc/dracut.conf.d/10-crypt.conf是否含install_items+=" /etc/crypttab "；mkinitcpio 用户确认HOOKS中encrypt和lvm2在filesystems之前 - 测试时可在
rd.shell中手动执行cryptsetup luksOpen /dev/sda2 cryptroot和vgscan && vgchange -ay，验证流程是否通
最常被忽略的是：initramfs 里的设备发现是静态的，不自动重试。哪怕你多等一分钟，它也不会“突然找到”设备 —— 它只在初始化阶段扫描一次。所以问题不在“时间”，而在“有没有让驱动和参数在那一刻就位”。