1. 问题现象安装进度条停住日志提示 EFI_RNG_PROTOCOL unavailable1.1 我的环境与第一次复现过程我在 Apple Silicon 芯片的 Mac 上用 VMware Fusion 装 Ubuntu 22.04 ARM64 时第一次撞见这个提示是在安装 Ubuntu Server 的界面里。当时虚拟机配置了 4 核 CPU、8GB 内存、80GB 虚拟磁盘镜像用的是官方 Ubuntu 22.04.3 live-server arm64 ISO引导方式选的是默认的 UEFI。安装器走到了“Storage configuration”这一步进度条停在了约三分之二的位置屏幕上没有任何进度变化底部的安装日志却一直在刷新同一行内容EFI_RNG_PROTOCOL unavailable。最开始我以为是网速问题导致安装包下载卡住于是关掉了网络重试没效果又怀疑是 ISO 镜像下载不完整重新校验 SHA256 后再次尝试问题依旧。折腾了两轮之后才意识到真正的问题不在镜像完整性而在虚拟机的固件协议层面。后来在系统日志里看到完整的报错信息EFI_RNG_PROTOCOL unavailable, falling back to EFI_GET_TIME这就把矛头指向了随机数熵源。1.2 该提示出现的三种常见位置根据我自己的复现和身边朋友的反馈这个提示一般出现在三个地方。第一处是 GRUB 引导之后、进入 Live 环境或安装程序之前的内核启动日志如果启动时按了 Esc 查看详细输出能看到它在引导早期就已经被打印出来。第二处是 Ubuntu Server 的 subiquity 安装器运行过程中主要出现在分区格式化、创建 LVM 卷、启用 LUKS 磁盘加密这些需要生成随机密钥的阶段。第三处是系统安装完成、重启进入新系统之后的 journalctl 或 dmesg 输出里这类情况下系统通常能正常启动但 SSH 主机密钥生成、GPG 初始化等操作会明显变慢。这个提示在不同场景下的表现差异很大。有的机器上它只是一条无害的 warning系统先用 EFI_GET_TIME 提供的低质量随机数兜底安装慢一些但最终能完成。有的机器上则直接表现为安装程序“假死”特别是当你勾选了全盘加密时系统需要调用密码学随机数来生成 LUKS 主密钥如果熵源迟迟不来getrandom() 系统调用会一直阻塞表面上看就是进度条再也不动。1.3 表面现象背后的真实风险很多人看到 “unavailable” 这个单词以为只是一条无关痛痒的提示但实际上它在本案例里是“虚拟固件没有向 Guest 系统提供 UEFI RNG 协议”的直接信号。Linux 拿不到固件随机数种子就会退回到用实时时钟EFI_GET_TIME这类弱熵源补充熵池。如果整个系统里没有其他可用的硬件随机数发生器熵池会长时间处于低熵状态。安装程序在这种状态下生成任何加密密钥都会因为无法获取足够的随机字节而卡住。换句话说这是一个“警告文案看起来温和、实际影响却很硬核”的问题。你在安装界面看到的是进度条卡住但在系统底层看到的是熵池长期见底、CRNG 初始化迟迟无法完成。理解了这一点后续的排查方向就非常清晰了所有有效的解法本质上都是在给这台虚拟机额外提供熵源。2. 根因分析Apple Silicon 虚拟机里为什么缺这个协议2.1 EFI_RNG_PROTOCOL 到底是什么EFI_RNG_PROTOCOL 是 UEFI 规范中定义的一项接口由固件向操作系统提供密码学安全的随机字节生成能力。说得直白一点它相当于 BIOS 或 UEFI 固件给系统开的一扇“随机数水龙头”系统启动早期就可以从这扇水龙头里接水把随机种子灌进内核的熵池。Linux 内核在启动阶段会主动探测这个协议具体逻辑在drivers/firmware/efi/efi.c里。如果探测成功内核会把固件提供的随机字节交给随机数子系统作为早期熵源如果探测失败就会打印类似 “EFI_RNG_PROTOCOL unavailable” 的日志并改用其他方案比如从 UEFI 的实时时钟读取当前时间来凑随机种子。时间本身就是一种低熵来源一秒之内的精度能提供的随机性非常有限所以这个回退方案只能保证系统不直接崩并不能保证后续的加密操作顺畅。2.2 VMware Fusion 在 Intel 平台和 Apple Silicon 平台的差异同样是 VMware Fusion在 Intel Mac 上很少看到这条告警但在 Apple Silicon 芯片的 Mac 上几乎是标配。原因在于两种平台的虚拟化底层完全不同。Intel Mac 上VMware Fusion 走的是传统的 x86 虚拟化路径Guest 系统可以直接使用 Intel 的 RDRAND 指令Linux 内核把 CPU 硬件随机数当作高质量熵源所以根本不依赖 EFI_RNG_PROTOCOL。到了 Apple Silicon 上VMware Fusion 基于 Apple 的 Virtualization.framework 构建虚拟机的 CPU 架构变成了 ARM64。ARM 处理器虽然也有硬件随机数指令ARMv8.5 的 RNDR/RNDRRS但虚拟化框架是否把这个特性透传给 Guest取决于实现细节。以 VMware Fusion 在 Apple Silicon 上的实现来看它的虚拟 UEFI 固件没有完整实现 EFI_RNG_PROTOCOL于是 Linux 内核从 UEFI 层获取随机数的通道被切断了。下面这个对比可以帮你快速理解两个平台差异对比项Intel Mac 上的 VMware FusionApple Silicon Mac 上的 VMware Fusion虚拟化底层x86 虚拟化Apple Virtualization.frameworkGuest CPU 架构x86_64ARM64可用的 CPU 随机源RDRAND 通常直接暴露RNDR/RNDRRS 视虚拟层透传情况虚拟 UEFI 是否实现 RNG 协议一般不影响因为有 RD RAND默认缺失导致 EFI_RNG_PROTOCOL 告警常见表现安装流程顺畅安装加密步骤可能卡住2.3 熵池不足引发的连锁反应内核熵池是 Linux 随机数子系统的核心可以把它理解成一个大水缸系统早期所有需要随机字节的程序都从这个水缸里取水。EFI_RNG_PROTOCOL 缺失后启动阶段能灌进水缸的水源少了一条如果其他水源比如虚拟硬件 RNG、CPU 随机指令也没有水缸水位就一直上不来。现代 Linux 内核里getrandom()系统调用在 CRNG 初始化完成之前会进入阻塞等待。Ubuntu 安装器在生成 LUKS 加密密钥、创建分区表时都会调用这类接口一旦随机数子系统尚未完成初始化等待就会无限拉长。这就是为什么问题明明只是一行提示却能让你在安装界面干等半小时的原因。这个过程可以类比成厨房里做菜盐瓶空了厨师不放下锅铲而是站在原地等盐送来菜就一直搁在锅里。虚拟机的处理器并没有转起来磁盘也没有写入只有日志在不断地重复同一行内容看起来像死了其实还在等“盐”。3. 排查链路先确认是不是熵源问题3.1 从启动日志确认 EFI 层行为遇到安装卡住先别急着重装。第一步应该是进入安装环境的 shell查一下系统日志确认这行告警是否真的来自 EFI 协议层。Ubuntu Server 安装器里按 CtrlAltF4 可以切换到命令行 shell执行下面的命令dmesg | grep -i -E efi|rng正常输出里会看到类似这样的内容EFI: EFI_RNG_PROTOCOL unavailable, falling back to EFI_GET_TIME如果看到了这一行说明问题确实出在固件协议缺失而不是安装器自身崩溃。接下来就可以把排查重点放到熵源上。如果没有 dmesg 权限可以改用journalctl -k | grep -i rng查看内核日志。3.2 检查当前熵池是否见底确认 EFI 告警之后第二步是查看当前系统的熵池状态。同样在 shell 里执行cat /proc/sys/kernel/random/entropy_avail这个文件会输出当前熵池的估算值单位是比特。在正常虚拟机上数值一般在几百左右在熵源稀缺的虚拟机上数值可能常年维持在 0 到几十之间。如果你发现数值很小且在反复读取时几乎没有增长说明系统的外部熵源确实不够“卡住”基本就是等待熵导致的了。需要说明的是现代内核的随机数模型已经不再完全由这个数值来决定阻塞行为但它仍然是一个很直观的参考指标。对新手来说这个数字就像汽车仪表盘上的油量油量见底去加油站加油总是没错的。3.3 区分“卡死”和“等待熵”安装进度条停在某个阶段时不要急着判定系统故障。用另一个终端循环观察熵池watch -n 1 cat /proc/sys/kernel/random/entropy_avail如果数值长时间停在个位数或十几几乎不动那就是在等待熵源。如果数值明显在波动说明系统还有活跃的熵源在工作安装慢但最终能完成。判断清楚这一点能帮你决定下一步是安装 haveged 还是继续耐心等待。同时可以观察安装程序的 CPU 和磁盘占用情况。等待熵的典型表现是虚拟机 CPU 占用很低磁盘几乎没有写操作屏幕上的安装日志却反复刷同一行告警。这种“低负载卡顿”和系统崩溃的“高负载异常”很容易区分前者基本可以认定是熵不足。4. 方案一安装阶段临时引入 haveged给内核喂熵4.1 为什么首选 haveged 而不是 rng-tools在虚拟机中解决熵源不足有两个常见工具haveged 和 rng-tools。rng-tools 的思路是从硬件随机数设备读数据比如 /dev/hwrng。但在这个场景下VMware Fusion 的 Apple Silicon 虚拟机默认没有暴露可用的硬件 RNG 设备你执行rng-tools的安装和启动之后rngd 很可能根本找不到输入源白忙一场。haveged 的思路完全不一样。它基于 HAVEGE 算法利用处理器指令执行时序、缓存命中率、分支预测等微架构层面的不可预测噪声来生成随机数不需要专用的虚拟 RNG 设备。换句话说在“固件协议缺失”的环境里haveged 仍然可以靠“处理器时序噪声”这种软方法凭空挤出靠谱的熵。下面是两者的直观对比工具熵源类型在 VMware Fusion ARM 虚拟机中的表现haveged处理器时序噪声HAVEGE 算法可用无需专用虚拟设备rng-tools硬件随机数设备 /dev/hwrng 等通常不可用因为找不到硬件源4.2 Desktop Live 环境里的完整操作步骤如果你手头是 Ubuntu 22.04 Desktop ARM64 镜像处理过程比较简单。用虚拟光驱加载 ISO 后开机在 GRUB 菜单选择 “Try or Install Ubuntu” 进入 Live 桌面然后按下面的顺序操作。第一步确认虚拟机网络通了。Live 环境的 NAT 网络一般会自动连通可以在终端里跑一下ping -c 4 archive.ubuntu.com能通再去装包。第二步打开终端执行sudo apt update sudo apt install -y haveged第三步确认服务已经起来systemctl status haveged看到active (running)的绿字就说明服务在跑。此时回到桌面重新点击“安装 Ubuntu”进入正式安装流程。关键点在于不要重启虚拟机。重启会丢掉 Live 环境里刚装的 haveged等于白做。安装结束后重启进入全新系统别忘了把 haveged 作为运行依赖安装到新系统里否则新系统未来启动时还会面临同样的熵源问题。4.3 Server 安装器subiquity里的临时 shell 方案如果你只有 Ubuntu Server 镜像没有 Live 桌面环境也别慌。subiquity 安装器预留了终端入口。开机进入安装器界面后按 CtrlAltF4 切换到 shell。在这个 shell 里你通常已经是 root 身份可以直接执行apt update apt install -y haveged装完确认服务正常后输入exit退出 shell然后按 CtrlAltF1 切回安装器主界面。有些版本里终端快捷键可能是 F2 或 F3具体看屏幕底部提示。切回去之后安装器不会立刻变化界面可能还停留在刚才卡住的进度条位置但不用担心给它几分钟时间它就能感知到熵池已经由 haveged 接管继续往下走。这个方案的核心思路是不让安装器自己干等而是人为在旁边搭一个“临时水泵”先把熵池水位抬起来等安装器需要随机数的时候随取随用。安装完成之后系统拿到的是已经写入磁盘的完整文件只差一份随机种子源这时再进系统补装 haveged 即可。4.4 安装完成后的熵源持久化安装阶段装的 haveged 只存在于 Live 会话里不会自动传递到新系统。所以装完系统、重启后第一件事就是把 haveged 安到新系统里sudo apt update sudo apt install -y haveged sudo systemctl enable --now havegedenable --now的意思是设置开机自启并立即启动。这一步做完即使未来虚拟机启动时依然出现 EFI_RNG_PROTOCOL unavailable 的提示也不会再因为没有熵源而卡住系统启动。SSH 主机密钥生成、LUKS 解锁这类操作都能正常推进。5. 方案二用 random.trust_cpuon 让内核信任 CPU 随机数5.1 参数背后的原理除了在用户态安装 haveged还可以尝试让内核直接信任 CPU 提供的随机数。Apple M 系列芯片内部是有硬件真随机数生成器的ARMv8.5 指令集里对应的指令是 RNDR/RNDRRS。问题在于虚拟化层是否愿意把这条指令透传给 Guest 系统使用。random.trust_cpuon这个内核参数的作用就是明确告诉内核把 CPU 随机数指令的输出当作可信熵源。如果你的虚拟层已经透传了 RNDR 指令那么这个参数会在启动早期就把 CPU 的硬件随机数灌入熵池EFI_RNG_PROTOCOL 缺失就不再是问题。如果虚拟层没有透传这个参数就会形同虚设。所以这个方案能不能生效取决于 VMware Fusion 版本以及虚拟 CPU 的特性暴露情况。实测中在部分版本上是有效的换到另一版本又可能完全无效。抱着“加一个参数试试”的心态来操作成本很低值得先试。5.2 安装引导时的临时启用方法在虚拟机开机进入 GRUB 菜单时按下键盘的e键进入引导项编辑界面。找到以linux开头的那一行这行通常包含/casper/vmlinuz或/install/vmlinuz之类的核心路径把光标挪到行尾追加参数random.trust_cpuon按 CtrlX 或者 F10 启动。注意不要修改行内其他内容只追加这一个参数。如果该参数生效安装过程中不会再出现无休止的等待日志里的 EFI_RNG_PROTOCOL 告警也可能不再出现。5.3 已装好系统时的永久配置如果系统已经装完想把参数写到 GRUB 配置里长期生效操作也不复杂sudo sed -i s/GRUB_CMDLINE_LINUX_DEFAULTquiet splash/GRUB_CMDLINE_LINUX_DEFAULTquiet splash random.trust_cpuon/ /etc/default/grub sudo update-grub sudo reboot重启之后用下面命令验证dmesg | grep -i random能看到与 CPU RNG 相关的初始化信息说明参数已经生效如果日志里没有相关的成功提示说明虚拟层没有透传这个特性继续用 haveged 方案即可。5.4 两个方案并行的思路我这里推荐的使用顺序是安装引导时先临时加random.trust_cpuon试一次如果安装不卡说明 CPU 随机源可用安装完成后把这个参数永久写进 GRUB。如果加参数后问题依旧说明虚拟层没有透传 RNDR此时再进入 Live 环境安装 haveged。这两个方案并不冲突。random.trust_cpuon是在内核层面启用 CPU 随机源haveged 是在用户态持续补充熵池。二者并行使用可以大幅降低这台虚拟机未来在其他场景下再次出现熵源不足的概率。特别是对于需要运行加密服务、区块链节点、密钥管理类应用的虚拟机把熵源做厚一点没有坏处。6. 长期维护与避免再次踩坑6.1 已安装系统持续报错时的处理思路如果你的虚拟机里已经反复出现这条告警系统也能进就是 SSH 服务启动慢、密钥生成卡顿处理方式其实和安装阶段大同小异——补装熵源、设为开机自启。我建议直接安装 haveged 并启用服务sudo apt update sudo apt install -y haveged sudo systemctl enable --now haveged装完之后用systemctl status haveged确认服务状态。如果遇到 rngd 找不到硬件源的情况不用管它haveged 已经接管熵源rngd 只是个可选项。也有人会再装一个 rng-tools 尝试读取虚拟硬件 RNG但在多数 VMware Fusion ARM 虚拟机上这个路径是走不通的。6.2 升级 VMware Fusion 与 Ubuntu 点版本可能直接解决问题这个问题本质上属于虚拟固件实现不完整所以软件版本更新是另一种可能更省事的解法。VMware Fusion 在 Apple Silicon 上的实现一直在完善某些后续版本通过更新虚拟 EFI 固件确实补上了 EFI_RNG_PROTOCOL。如果你有条件先升级到最新的 VMware Fusion 再重新创建或启动虚拟机问题可能直接消失。Ubuntu 系统镜像这边也建议多试几个点版本。22.04.1、22.04.2、22.04.3 的安装器行为不完全一样个别点版本对随机数的初始化顺序做了调整换一个点版本可能就不再触发这个问题。在正式选择长期使用的镜像前花十几分钟换版本试装一次比在固定版本上反复折腾更有效率。6.3 调整虚拟硬件配置以减少触发概率虽然根因在固件协议但合理配置虚拟机硬件能降低问题扩大化的概率。给虚拟机分配至少 2 核 CPU 和 4GB 以上内存避免资源过小导致系统初始化流程被拖慢让熵池问题更早暴露。安装时如果不需要 LUKS 全盘加密可以先不勾选加密选项这样安装器就不会在熵池不足时强制生成加密主密钥绕开最容易卡住的那一步。不过要注意绕过加密只是避开触发场景并没有根治熵源问题。如果你后续想在系统里启用 LUKS、创建远程证明、跑数据库 TLS熵池不足的问题迟早还会冒头。所以最终仍然建议在系统里保证 haveged 处于运行状态或者用一个可靠的内核参数维持熵源。6.4 记录一份可复现的检查清单把整个过程整理成清单下次再遇到或者帮别人解决时可以直接照做进入安装器 shell用dmesg | grep -i rng确认是否存在 EFI_RNG_PROTOCOL 告警。用cat /proc/sys/kernel/random/entropy_avail查看熵池数值判断是否长期处于低水位。尝试在 GRUB 引导参数中追加random.trust_cpuon看是否能让内核直接使用 CPU 随机源。如果无效在 Live 环境或安装器 shell 中安装haveged作为临时熵源完成安装。新系统装完立即安装并启用haveged确保后续启动不再出现熵源断档。升级 VMware Fusion、更换 Ubuntu 点版本从源头降低复现概率。我在实际处理这个问题时最大的感受是别被“unavailable”这个单词吓住也别急着重装系统。它更像一台汽车告诉你“油表传感器坏了”而不是“发动机报废了”。你只需要另外想办法补油车就能继续跑。把熵源补上这行告警就算还在日志里出现也无伤大雅了。如果这些方案都试过还是卡可以把虚拟机换成其他虚拟化方案再装装好后再把磁盘带回 VMware 用也算一个不算优雅但能救急的路子。
