VMware Workstation Linux Kernel Headers Error: Version Matching, Build, and Secure Boot Diagnosis

“Kernel headers for version … not found” means only that VMware could not prepare the vmmon and vmnet modules for the current Linux host kernel. It does not mean that installing any headers package will solve the problem. First prove that the host OS, running kernel, and VMware product version are an officially supported combination. Then examine the exact development package, build toolchain, build logs, and Secure Boot signature separately.

Table of Contents

1. Distinguish four failures first

Stage	Typical evidence	Direction
Build tree not found	`/lib/modules/current-kernel/build` is absent, unreadable, or a broken target	Install official headers/devel that exactly match the running kernel
Compilation fails	`vmware-modconfig` log reports compiler, API, Makefile, or dependency errors	Check toolchain and VMware/kernel compatibility; do not conceal it with third-party patches
Build succeeds but module will not load	`modinfo` finds the module; kernel log reports signature, key, or lockdown	Keep Secure Boot and sign/enroll both modules through VMware and distro procedures
Unsupported product/host	The official matrix omits the distro, kernel, architecture, or product combination	Stop patching; plan a VMware upgrade or migration to a supported host combination

Identify the stage before acting. Correct headers cannot repair an incompatible kernel API. A successful build also does not prove that Secure Boot will permit the module to load.

2. The support matrix is the first gate

Record the complete VMware version, Linux distribution release, uname -r, and uname -m, then compare every value with Broadcom's current Workstation Pro/Player host support matrix. The matrix is specific to product version, distribution point release, and kernel ceiling. “Linux runs” or “the distribution is maintained” does not mean VMware supports that combination. Host support and guest OS support are also different questions.

As checked on 2026-09-01, the matrix lists specific Ubuntu, Debian, Fedora, RHEL, SUSE/openSUSE, and other combinations, but does not list Arch Linux as a supported host. Arch's headers documentation can explain version matching; it cannot make that host a VMware-supported combination. Custom, mainline, real-time, cloud-vendor, and rolling-release kernels also require explicit verification rather than inference from the distribution name.

If the current combination is absent, do not randomly downgrade a kernel, copy headers from another version, apply a community patch, or force a module past vermagic. Supported paths are to use a vendor-supported VMware and host/kernel combination or obtain an exception from Broadcom and the distribution vendor.

3. Start with a read-only inventory

Shut down VMs cleanly and save work, but do not install, reboot, sign, or rebuild yet. These commands collect versions, paths, and status only. A line may fail when an optional tool is absent; that failure is evidence to record.

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'

Before sharing logs, redact usernames, hostnames, paths, VM names, licensing data, and network details. Do not upload all of /tmp, a complete system journal, VM configurations, or disks. Record command exit status. Empty output, permission denial, and a missing command cannot be reported as “healthy.”

4. Match the exact running kernel

The full output of uname -r is the target, including distribution release, flavor, and architecture suffix. /lib/modules/$(uname -r)/build should be provided by the distribution for that kernel and resolve to a usable configured build tree. A user-space API kernel-headers package alone is often insufficient for external modules. Fedora, for example, defines kernel-devel as the headers and Makefiles for building modules against the matching kernel, while kernel-headers serves user-space libraries.

Do not manually link to a “close enough” tree or copy /usr/src from another computer or kernel. Kernel release, configuration, generated headers, symbol versions, and compiler assumptions may differ. A module might finish compiling yet be rejected at load or be unsafe.

If a new kernel was installed but the host has not rebooted, the current target remains the old uname -r. Either obtain the exact package for that running kernel or, during a maintenance window with console rollback, boot an installed supported new kernel. Never mix the two versions.

5. Verify packages by distribution before guessing an install command

Use the distribution package database first to identify which package owns the files. All commands below are read-only.

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 with the 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's standard kernel, for package identification only and not proof of VMware support:

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

Low-latency, real-time, LTS, debug, and custom flavors use different package names. If no exact release is found, do not treat a metapackage's “latest” version as the running version, and do not search unofficial repositories for an approximate package.

6. Install exact dependencies only on a supported combination

For a supported Debian/Ubuntu combination where the official repositories provide the exact running-kernel package, run this only in an approved maintenance window:

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

For a supported Fedora combination, Fedora's module development package and Broadcom's prerequisites correspond to:

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

On SUSE/openSUSE, use official kernel-devel/kernel-default-devel packages that match the current kernel flavor/release and the compiler required by that distribution. Leap 16 release notes specifically warn that modules must use the same compiler version that built the kernel. Do not copy a GCC package name from one release into another. Use YaST, official repositories, and that release's documentation to select exact packages.

Stop if the package manager says the exact package does not exist. Common causes are a running kernel already retired from repositories, incomplete repositories, a custom kernel, or an unsupported host combination. Do not turn that failure into an approximate-version install.

7. The compiler and toolchain are part of the match

/proc/version normally records the compiler used for the kernel. Compare it with gcc --version, the linker, and Make. Different version text is not automatically fatal, but compiler mismatch, missing cc, make, perl, ELF development files, or warnings promoted to errors in the build log must be resolved using support material for that distribution and VMware release.

Do not edit Makefiles, disable warnings, fake a compiler version, or download prebuilt vmmon.ko/vmnet.ko from an unknown source. External modules must be built against the accurate tree. Kernel documentation also explains that version magic and symbol versions participate in load checks.

8. Rebuild in a maintenance window and retain the log

Only after the support matrix, exact build tree, and toolchain pass should you stop every VMware VM and service and run VMware's bundled module configurator from a terminal. The timestamped log name refuses overwrite, and pipefail preserves the build exit code.

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 also says install/first-launch logs may appear at /tmp/vmware-root/vmware-PID.log. Read the newest log that matches the relevant PID and time; do not confuse an older failure with the current run. Do not auto-delete logs. First preserve the exit code, VMware version, kernel version, and package-query results.

9. Verify module identity after a successful build

Before loading, verify where each module came from, which kernel it targets, and who signed it:

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 should be compatible with the current kernel, and the file should be under that kernel's module tree. An empty signer does not prove failure by itself; combine it with Secure Boot status and the kernel log. Never use modprobe --force-vermagic, insmod --force, or disabled signature enforcement to pass a test.

10. Secure Boot: build and load are separate gates

Broadcom states that with Secure Boot enabled, both vmmon and vmnet must be signed or VMs cannot start. Ubuntu, Debian, and SUSE documentation likewise requires trusted signatures for self-built external modules under Secure Boot.

Broadcom's signing KB uses an older Workstation/Ubuntu environment and explicitly notes that commands vary by distribution. Use it to establish the product boundary that both modules require signatures, then use current distribution documentation for the actual sign-file, MOK paths, and key-management procedure. Do not copy old paths verbatim.

Do not disable Secure Boot as a “fix.” Follow the current VMware KB and the distribution's MOK/module-signing process. Protect private keys and never place them in a shared directory, support ticket, or log. Confirm MOK enrollment at a physical or out-of-band console, sign both modules, and verify again after every module rebuild. Signing, key enrollment, and reboot are security-state changes that require approval from the device owner.

If the modules built but modprobe or VMware startup reports Key was rejected, Required key not available, signature, or lockdown errors, return to the signing process instead of rebuilding headers repeatedly.

11. Do not confuse DKMS, distribution packages, and VMware’s installer

DKMS can rebuild external modules after kernel updates, but VMware's official installer normally builds vmmon/vmnet through vmware-modconfig. dkms status is authoritative only when distribution packaging explicitly registered those modules. The mere presence of DKMS does not mean it manages VMware modules.

Do not mix the Broadcom bundle, a distribution package, an AUR/community package, and third-party module sources. Determine ownership through the package manager and installation records first. Unknown or duplicate ownership is a stop condition until an administrator selects one supported installation path.

12. Evidence-to-next-step matrix

Evidence	Conclusion boundary	Next step
`build` path absent; exact package exists in official repository	Build dependency missing	Install exact official devel/headers and toolchain; check the path again
Exact package unavailable	Old/custom kernel, repository, or support issue	Do not install an approximation; check repositories, booted kernel, and matrix
Build log reports kernel API errors	Headers are not necessarily wrong	Verify VMware/kernel support and escalate to the vendor
Log reports compiler/ELF/Make dependency	Toolchain incomplete or mismatched	Use official distro build dependencies and required compiler
`modinfo` finds modules; log rejects key	Secure Boot load failure	Sign and enroll `vmmon` and `vmnet`; keep Secure Boot enabled
`vermagic` incompatible with `uname -r`	Module was built for another kernel	Stop loading; rebuild for the current supported kernel
Arch/custom/mainline kernel absent from matrix	No proof of vendor support	Migrate to a supported combination or open a vendor case
Remote host loses boot or networking after change	Boot/remote rollback event	Use out-of-band console, select known-good kernel, and restore

13. Remote hosts, reboot, and rollback

Before installing a kernel, enrolling a MOK, or rebooting, have a maintenance window, clean VM shutdown record, independent backups of critical VMs, current package/kernel inventory, a known-bootable vendor kernel, boot-menu access, and physical or out-of-band console. A snapshot is not an independent backup.

Do not remove the running kernel or the only known-good kernel. Stop before reboot on a remote system without verified console access. If a new kernel breaks boot, networking, or VMware, choose the retained known-good vendor kernel from the boot menu. Verify networking and storage before using the distribution package manager to handle the failed version; do not manually delete /lib/modules.

If a VMware update caused the failure, use pre-change official media/packages and vendor documentation for an approved rollback, or restore a tested host backup. Do not seek “something that compiles” with a random older product or kernel. After rollback, recheck the support matrix, module paths, signatures, and VM startup tests.

14. Stop and escalate in these cases

The host distribution, release, architecture, kernel, or VMware product is absent from the current support matrix.
The kernel is custom, mainline, real-time, a vendor preview, or too old to have an exact development package.
Progress requires a third-party patch, unknown module binary, forced vermagic, copied headers, or disabled Secure Boot.
The build log contains unexplained kernel API, symbol-version, signature, license, or compiler errors.
The host carries production VMs but lacks backups, a maintenance window, a known-good boot entry, or console rollback.
Modules/install files have multiple package-manager owners, or log origin, time, and target kernel cannot be correlated.

Send the inventory, exact support-matrix row, package queries, build exit code, narrowly redacted relevant log, modinfo, and kernel log to Broadcom, the distribution vendor, or the host administrator.

15. Completion checklist

[ ] Complete VMware version, distribution, architecture, and full uname -r are recorded.
[ ] The exact host/product/kernel combination is confirmed in the current Broadcom matrix.
[ ] build points to a readable official tree for the current kernel, not a manual link or copied directory.
[ ] Headers/devel, user-space headers, toolchain, and VMware compatibility are distinguished.
[ ] Every package is from official distro repositories and exactly matches the running kernel/flavor.
[ ] Build ran with VMs stopped in a maintenance window; exit code and corresponding log are retained.
[ ] vmmon and vmnet paths, vermagic, signatures, and kernel log were checked.
[ ] Secure Boot remains enabled; both modules are signed/enrolled through official procedures if needed.
[ ] No third-party patch, unknown module, forced load, copied headers, or random downgrade was used.
[ ] Independent backups, a known-good kernel, and physical/out-of-band rollback exist before reboot.

16. Official sources

Sources checked on 2026-09-01. Support matrices and kernel ceilings change; reopen the current pages before acting instead of relying only on this article's date.

17. Original 2013 archive (provenance only)

The fence preserves the complete visible source_export body verbatim. No trailing whitespace normalization or private-value redaction was needed. The incomplete shell variable, malformed historical kernel version, and obsolete HTTP reference remain inert historical evidence, not a current command or recommended link.

~~~~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
~~~~