内核升级后initramfs缺virtio_blk解决办法

内核升级后因 initramfs 缺失 virtio_blk 模块导致系统启动卡在“Waiting for root device…”？根本原因在于 dracut 无法自动推导 virtio 子模块依赖，而 `--add-drivers "virtio"` 实际无效——因为 virtio 并非可加载模块，而是总线前缀；正确做法是显式指定 `virtio`（小模块）、`virtio_ring` 和 `virtio_blk` 三者，并验证其在新内核中是否为模块（`=m`）或已内置（`=y`），再配合 `dracut -f --regenerate-all` 强制重建匹配的 initramfs，避免沿用旧镜像引发启动失败。

dracut --add-drivers "virtio" 为什么加不进 virtio_blk？

因为 virtio 不是内核模块名，而是一个总线前缀；virtio_blk 是独立模块，dracut 不会自动推导子模块。用 --add-drivers "virtio" 实际上什么也没加进去——内核里没有叫 virtio 的可加载模块，lsmod | grep virtio 也看不到它。

正确写法：明确指定 virtio_blk 和依赖模块

在 KVM/QEMU 虚拟机中，virtio_blk 依赖 virtio_ring 和 virtio（注意：这里的 virtio 是一个极小的通用模块，不是总线名），必须一并加入：

• dracut -f --regenerate-all --add-drivers "virtio virtio_ring virtio_blk"
• 如果还用到网卡，顺手加上 virtio_net
• 检查是否生效：lsinitrd /boot/initramfs-$(uname -r).img | grep -E "(virtio|blk)"

升级内核后 initramfs 没自动重建？别只信 dracut 配置文件

很多发行版（如 RHEL/CentOS 8+、Fedora）默认启用 dracut-install 触发机制，但内核升级时若未调用 kernel-install 或 dracut --regenerate-all，旧 initramfs 仍会被沿用。常见表现是：新内核启动卡在 “Waiting for root device…”。

• 确认当前 initramfs 是否匹配新内核：lsinitrd /boot/initramfs-$(uname -r).img | head -n5 看时间戳和内核版本
• 强制重建：dracut -f --regenerate-all（加 -v 可看模块加载日志）
• 某些系统需先 dracut --force 再 --regenerate-all，否则跳过已存在的镜像

virtio_blk 在 initramfs 里没加载？检查内核配置和模块路径

即使 dracut 加了驱动，启动时仍可能报 Failed to load module virtio_blk，原因通常是：

• 新内核编译时把 CONFIG_VIRTIO_BLK=m 改成了 =y（内置），此时模块文件 virtio_blk.ko.xz 根本不存在，dracut 找不到它，也就不会打包进 initramfs
• 检查：zcat /lib/modules/$(uname -r)/modules.builtin | grep virtio_blk，若输出非空，说明它是 builtin，无需 dracut 加载，但需确保 root 设备识别逻辑兼容（比如使用 root=PARTUUID=... 而非依赖模块探测）
• 若为 =m，但 find /lib/modules/$(uname -r) -name 'virtio_blk*' 无结果，说明模块未安装，需重装 kernel-modules 包或重新 make modules_install

dracut 对模块名极其严格，拼错、漏依赖、或模块实际不存在，都会静默失败。最稳的方式是：先确认模块存在且可 modprobe，再让 dracut 显式列出来。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。