VMware Workstation Linux 内核头文件错误：匹配版本、编译与 Secure Boot 诊断

“Kernel headers for version … not found”只说明 VMware 无法为当前 Linux 宿主内核完成 vmmon、vmnet 模块准备工作，不等于“随便安装一个 headers 包”就能解决。先证明宿主操作系统、正在运行的内核和 VMware 产品版本属于官方支持组合，再分别检查精确的开发包、编译工具链、构建日志和 Secure Boot 签名。

Table of Contents

1. 先区分四种失败

阶段	典型证据	处理方向
找不到构建树	`/lib/modules/当前内核/build` 不存在、不可读或指向无效目标	安装与正在运行内核完全匹配的官方 headers/devel 包
编译失败	`vmware-modconfig` 日志含编译器、API、Makefile 或缺失依赖错误	核对工具链与 VMware/内核兼容性，不用第三方补丁掩盖
编译成功但模块无法加载	`modinfo` 能找到模块，内核日志报告签名、密钥或 lockdown	保持 Secure Boot，按 VMware 与发行版流程签署并登记两个模块
产品/宿主不受支持	官方支持矩阵没有该发行版、内核、架构或产品组合	停止修补；规划升级 VMware 或迁移到受支持宿主组合

先看错误发生在哪一阶段。headers 正确并不能修复内核 API 不兼容；编译成功也不能证明 Secure Boot 会允许模块加载。

2. 支持矩阵是第一道闸门

记录 VMware 的完整版本、Linux 发行版版本、uname -r 和 uname -m，逐项对照 Broadcom 当前的 Workstation Pro/Player 宿主支持矩阵。矩阵按产品版本、发行版小版本和内核上限列出；“Linux 可运行”或“发行版仍受维护”不代表这个组合受 VMware 支持。宿主支持与虚拟机中的 guest OS 支持也不是同一件事。

截至 2026-09-01，矩阵列出特定 Ubuntu、Debian、Fedora、RHEL、SUSE/openSUSE 等组合，但没有把 Arch Linux 列为受支持宿主。Arch 的 headers 文档可帮助解释版本匹配，却不会把该宿主变成受 VMware 支持的组合。自定义、主线、实时、云厂商或滚动发行内核也必须逐项核对，不能从同一发行版名称推定支持。

如果当前组合不在矩阵中，不要随机降级内核、复制其他版本的 headers、安装社区补丁或强行忽略 module vermagic。可支持的路径是：使用供应商支持的 VMware 版本和宿主/内核组合，或向 Broadcom 与发行版供应商确认例外。

3. 先做只读清点

关闭虚拟机并保存工作，但先不要安装、重启、签名或重编译。下面的命令只收集版本、路径和状态；某个可选工具不存在时，其行可能失败，这也是需要记录的证据。

uname -r
uname -m
cat /etc/os-release
vmware --version
command -v vmware vmware-modconfig gcc cc make perl ld mokutil dkms
cat /proc/version
gcc --version
make --version
ld --version
readlink -f "/lib/modules/$(uname -r)/build"
stat "/lib/modules/$(uname -r)/build"
if test -r "/lib/modules/$(uname -r)/build/Makefile"; then echo build_tree_readable=yes; else echo build_tree_readable=no; fi
command -v mokutil >/dev/null && mokutil --sb-state
command -v dkms >/dev/null && dkms status
modinfo vmmon
modinfo vmnet
lsmod | grep -E '^(vmmon|vmnet) '
find /tmp/vmware-root -maxdepth 1 -type f -name 'vmware-*.log' -print 2>/dev/null
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|module|signature|secure boot|lockdown'

公开日志前遮盖用户名、主机名、路径、虚拟机名称、许可证信息和网络信息。不要上传整个 /tmp、完整系统日志、VM 配置或磁盘。记录命令退出状态；空输出、权限不足和命令不存在都不能被写成“正常”。

4. 精确匹配的是正在运行的内核

uname -r 的完整字符串是目标，包括发行版 release、flavor 和架构后缀。/lib/modules/$(uname -r)/build 应由发行版为该内核提供，并指向可用的、已配置的构建树。只有用户空间 API 的 kernel-headers 包通常不足以构建外部模块；例如 Fedora 明确把 kernel-devel 定义为构建匹配内核模块所需的 headers 和 Makefile，而 kernel-headers 面向用户空间库。

不要手工创建指向“差不多版本”的软链接，也不要把另一台机器或另一个内核的 /usr/src 复制过来。内核 release、配置、生成头文件、符号版本和编译器假设可能不同；即使编译结束，模块也可能拒绝加载或不安全。

如果刚安装了新内核但还没有重启，当前目标仍是旧的 uname -r。可以为旧运行内核取得精确包，也可以在有回退和控制台的维护窗口启动到已安装且受支持的新内核；不要混用两套版本。

5. 按发行版验证包，不先猜安装命令

先使用对应发行版的包数据库确认文件由哪个包提供。以下都是只读检查。

Debian/Ubuntu：

dpkg-query -W "linux-image-$(uname -r)" "linux-headers-$(uname -r)" build-essential gcc make perl
apt-cache policy "linux-headers-$(uname -r)" build-essential gcc make perl
dpkg-query -S "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

Fedora：

rpm -q "kernel-core-$(uname -r)" "kernel-devel-$(uname -r)" gcc make perl elfutils-libelf-devel
dnf info "kernel-devel-$(uname -r)"
rpm -qf "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

SUSE/openSUSE 的 default flavor：

rpm -q kernel-default kernel-default-devel gcc make perl
zypper search --installed-only --details kernel-default kernel-default-devel gcc make perl
rpm -qf "$(readlink -f "/lib/modules/$(uname -r)/build")/Makefile"

Arch 标准内核，仅用于识别包，不代表 VMware 支持：

pacman -Qo "$(readlink -f "/usr/lib/modules/$(uname -r)/build")/Makefile"
pacman -Q base-devel

低延迟、实时、LTS、debug 或自定义 flavor 的包名不同。若查询不到精确 release，不要把元包的“最新版本”当成当前运行版本，也不要从非官方仓库寻找近似包。

6. 只在支持组合上安装精确依赖

对受支持的 Debian/Ubuntu 组合，官方仓库能提供当前运行内核的精确包时，可在批准的维护窗口运行：

sudo apt update
sudo apt install "linux-headers-$(uname -r)" build-essential

对受支持的 Fedora 组合，Fedora 的模块构建包与 Broadcom 的前置条件对应：

sudo dnf install "kernel-devel-$(uname -r)" gcc make perl elfutils-libelf-devel

SUSE/openSUSE 应使用匹配当前 kernel flavor/release 的官方 kernel-devel/kernel-default-devel 与发行版要求的编译器。Leap 16 的发行说明特别提示，构建模块必须使用与内核相同的编译器版本；不要把某一版的 GCC 包名复制到其他版本。用 YaST、官方仓库和该发行版文档选择精确包。

若包管理器说精确包不存在，停止。常见原因是运行着已从仓库淘汰的旧内核、启用了不完整仓库、使用自定义内核，或宿主组合不受支持。不要将失败改写成一个近似版本的安装。

7. 编译器和工具链也属于匹配关系

/proc/version 通常记录构建内核所用编译器；将其与 gcc --version、链接器和 Make 比较。版本文本不同不一定必然失败，但构建日志中的 compiler mismatch、缺少 cc、make、perl、ELF 开发文件或警告升级为错误，都必须按该发行版与 VMware 的支持资料处理。

不要通过改 Makefile、关闭警告、伪造编译器版本或从未知来源下载预编译 vmmon.ko/vmnet.ko 来绕过。外部模块必须针对准确构建树构建；内核文档也说明版本魔数和符号版本会参与加载检查。

8. 在维护窗口重建并保留日志

只有支持矩阵、精确构建树和工具链都通过后，才停止所有 VMware 虚拟机和服务，在终端运行 VMware 自带的模块配置器。日志文件名使用时间戳且拒绝覆盖；退出码由 pipefail 保留。

LogPath="vmware-modconfig-$(date +%Y%m%d-%H%M%S).log"
test ! -e "$LogPath" || exit 1
set -o pipefail
sudo vmware-modconfig --console --install-all 2>&1 | tee "$LogPath"

Broadcom 还说明安装/首次启动日志可能位于 /tmp/vmware-root/vmware-PID.log。优先读取最新一次对应 PID/时间的日志，不要把旧失败与本次运行混在一起。不要自动清理日志；先保存退出码、VMware 版本、内核版本和包查询结果。

9. 构建成功后验证模块身份

在加载前先核对模块来自哪里、为哪个内核构建、由谁签名：

uname -r
modinfo -F filename vmmon
modinfo -F vermagic vmmon
modinfo -F signer vmmon
modinfo -F filename vmnet
modinfo -F vermagic vmnet
modinfo -F signer vmnet
journalctl -k -b --no-pager | grep -Ei 'vmmon|vmnet|signature|secure boot|lockdown'

vermagic 应与当前内核相容，文件应在当前内核的模块树中。signer 为空并不单独证明故障；结合 Secure Boot 状态和内核日志判断。不要用 modprobe --force-vermagic、insmod --force 或关闭签名强制来通过测试。

10. Secure Boot：构建和加载是两道门

Broadcom 明确指出，启用 Secure Boot 时，vmmon 和 vmnet 都必须签名，未受信任的模块会导致虚拟机无法启动。Ubuntu、Debian 和 SUSE 的文档也说明，Secure Boot 下自建外部模块需要可信签名。

Broadcom 的签名 KB 以较旧的 Workstation/Ubuntu 环境为例，并明确提示不同发行版的命令会变化。应把它用于确认“两个模块都要签名”的产品边界，再以当前发行版文档确定实际 sign-file、MOK 路径和密钥管理步骤；不要照抄旧路径。

不要关闭 Secure Boot 作为“修复”。使用当前 VMware KB 和发行版的 MOK/模块签名流程；保护私钥，不把它放进共享目录、工单或日志；在物理或带外控制台确认 MOK 登记；签名两个模块，并在每次模块重建后重新验证。签名、登记密钥和重启都是安全状态变更，应由设备所有者审批。

如果模块已构建但 modprobe 或 VMware 启动时报 Key was rejected、Required key not available、signature 或 lockdown 错误，回到签名流程，不要继续重编译 headers。

11. DKMS、发行版包与 VMware 安装器不要混为一谈

DKMS 可在内核更新后重建外部模块，但 VMware 官方安装器通常由 vmware-modconfig 构建 vmmon/vmnet。只有发行版包装明确注册了对应模块时，dkms status 才是权威证据。不要因为系统安装了 DKMS 就推定 VMware 模块受它管理。

同样，不要混装 Broadcom bundle、发行版包、AUR/社区包和第三方模块源码。先用包管理器和安装记录确定所有权；未知来源或重复所有权应停止并由管理员选择一种受支持安装路径。

12. 症状到下一步的矩阵

证据	结论边界	下一步
`build` 路径缺失，精确包在官方仓库可用	构建依赖缺失	安装精确官方 devel/headers 与工具链，再复查路径
精确包不可用	旧/自定义内核、仓库或支持问题	不装近似包；核对仓库、启动内核和支持矩阵
编译日志报内核 API 错误	headers 不一定有问题	核对 VMware 与内核支持；向供应商升级
编译日志报 compiler/ELF/Make 依赖	工具链不完整或不匹配	使用发行版官方构建依赖和规定编译器
`modinfo` 有模块，日志拒绝密钥	Secure Boot 加载失败	签署并登记 `vmmon`、`vmnet`，保持 Secure Boot
`vermagic` 与 `uname -r` 不相容	模块为另一个内核构建	停止加载，为当前受支持内核重新构建
Arch/自定义/主线内核不在矩阵	无供应商支持证明	迁移到受支持组合或开供应商工单
更新后远程主机无法启动或联网	启动/远程回退事件	使用带外控制台选已知良好内核并恢复变更

13. 远程主机、重启和回退

安装新内核、登记 MOK 或重启前，应有维护窗口、VM 正常关机记录、关键 VM 的独立备份、当前包/内核清单、已知可启动的供应商内核、启动菜单访问方式和物理/带外控制台。快照不是独立备份。

不要删除正在运行的内核或唯一的已知良好内核。远程机器没有可验证控制台时，停止在重启前。若新内核导致启动、网络或 VMware 回归，从启动菜单选择保留的已知良好供应商内核，验证网络和存储后再用发行版包管理器处理失败版本；不要手工删除 /lib/modules。

若失败来自 VMware 更新，使用变更前保存的官方安装介质/包和供应商文档执行已批准回退，或恢复经过测试的主机备份。不要用随机旧版产品或内核追求“能编译”。回退后再次核对支持矩阵、模块路径、签名和 VM 启动测试。

14. 必须停止并升级处理的情况

宿主发行版、版本、架构、内核或 VMware 产品不在当前支持矩阵。
内核是自定义、主线、实时、供应商预览版或已停止提供精确开发包的旧版本。
只能通过第三方补丁、未知模块二进制、强制 vermagic、复制 headers 或关闭 Secure Boot 才能继续。
构建日志含未知内核 API、符号版本、签名、许可证或编译器错误。
主机承载生产 VM，却没有备份、维护窗口、已知良好启动项或控制台回退。
模块/安装文件有多个包管理器所有者，或日志来源、时间和目标内核无法对应。

将清点结果、支持矩阵行、精确包查询、构建退出码、经过遮盖的相关日志、modinfo 和内核日志提交给 Broadcom、发行版供应商或负责该主机的管理员。

15. 完成检查清单

[ ] 已记录 VMware 完整版本、发行版、架构和完整 uname -r。
[ ] 已在当前 Broadcom 支持矩阵确认精确宿主/产品/内核组合。
[ ] build 指向当前内核的可读官方构建树，而非手工链接或复制目录。
[ ] 已区分 headers/devel、用户空间 headers、工具链和 VMware 兼容性。
[ ] 所有包来自发行版官方仓库且与运行内核/flavor 精确对应。
[ ] 构建在 VM 停止的维护窗口执行，退出码和对应日志已保存。
[ ] 已核对 vmmon、vmnet 的文件路径、vermagic、签名和内核日志。
[ ] Secure Boot 保持启用；需要时两个模块均按官方流程签署和登记。
[ ] 未使用第三方补丁、未知模块、强制加载、headers 复制或随机降级。
[ ] 重启前具备独立备份、已知良好内核和物理/带外回退路径。

16. 官方资料

资料核验于 2026-09-01。支持矩阵和内核上限会变化；执行前重新查看当前页面，不要只依赖本文日期。

17. 2013 年原文档案（仅供溯源）

以下围栏逐字保留 source_export 的完整可见正文；没有尾随空白规范化或私密值遮盖。档案中的不完整 shell 变量、错误的历史内核版本格式和已过时 HTTP 参考仅作为惰性历史证据，不是现行命令或推荐链接。

~~~~markdown

在Ubuntu终端下执行

sudo apt-get install linux-headers-$

eg.
sudo apt-get install linux-headers-3.5.0.25-generic

Referer link:
http://www.vi-toolkit.com/wiki/index.php/Build_host_vmware_kernel_modules
~~~~