Linux内核启动时crng init卡住是因等待足够熵，属主动保护机制；推荐优先使用rng-tools5配合virtio-rng硬件透传，haveged在虚拟机中熵质量不可靠。
为什么 crng init 卡住几分钟？
Linux 内核在启动时会等待足够的熵（entropy）来初始化密码学随机数生成器（CRNG），表现为 dmesg 中卡在 random: crng init done 之前，且系统响应迟缓。这不是 bug，而是内核的主动保护机制：没有足够熵时，/dev/random 会阻塞，连带影响 sshd、systemd、容器拉起等依赖随机源的服务。
haveged 和 rng-tools 哪个更靠谱？
两者都试图向内核熵池注入熵，但原理和稳定性差异明显：
-
haveged基于 CPU 时间戳抖动提取熵，无需硬件支持，但在虚拟机（尤其是 KVM/QEMU）中可能因定时器虚拟化失真导致熵质量低，甚至被内核拒绝（haveged: getrusage() failed或静默不注入） -
rng-tools是传统方案，需配合硬件 RNG 设备（如/dev/hwrng）；在无硬件时可启用--fill-watermark模式轮询注入，但若底层没可用 RNG，它会空转或报错Failed to open entropy source /dev/hwrng - 现代推荐优先用
rng-tools5（Debian/Ubuntu）或rng-tools（RHEL/CentOS 8+），并确保配置指向真实熵源
virtio-rng 在 KVM 虚拟机里怎么配才生效？
这是最干净的解法——把宿主机的硬件 RNG 透传给客户机。但常见失效点不在客户机配置，而在宿主机和 QEMU 启动参数：
- 宿主机必须有可用 RNG 设备（
ls -l /dev/hwrng存在且可读），常见于 Intel RDRAND（rdrand模块已加载）或 AMDrng_core+tpm-rng - QEMU 启动时需显式添加：
-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -object rng-random,filename=/dev/hwrng,id=rng0 - 客户机内核需启用：
CONFIG_HW_RANDOM_VIRTIO=y（通常默认开启），启动后应看到dmesg | grep -i rng输出virtio_rng virtio0: registered as random source - 验证是否生效：
cat /sys/devices/virtual/misc/hwrng/rng_current应返回virtio_rng；watch -n1 'cat /proc/sys/kernel/random/entropy_avail'启动后应快速升至 2000+，而非长期卡在 100–200
绕过 crng init 卡顿的临时手段（慎用）
仅限调试或嵌入式受限环境，生产系统不建议：
- 加内核启动参数：
random.trust_cpu=on（告诉内核信任 RDRAND/AMD X86_RDRAND 指令产出的熵），适用于较新 CPU 且 BIOS 开启了相关特性 - 强制提前初始化：
echo 1 > /proc/sys/kernel/random/urandom_min_reseed_secs（无效）；真正起效的是在 initramfs 阶段注入熵，例如在 dracut 配置中加入rd.random=1并确保rng-tools已打包进 initramfs - 绝对不要用
rngd -r /dev/urandom—— 这是用伪随机数充熵，违反密码学前提，crng init可能跳过但后续密钥极可能被预测
真正卡住时，先看 dmesg | grep -i -E 'random|rng|entropy'，再确认 /dev/hwrng 是否存在、virtio-rng 设备是否被识别、rngd 进程是否在跑且没报 open 失败——多数问题出在链路断在第一环，而不是工具选错。
