If you’ve ever tried to start VMware on a Linux machine and hit an error about vmmon or vmnet modules failing to load, there’s a good chance Secure Boot is the culprit. This guide walks you through exactly what’s happening and gives you two ways to fix it — the quick-and-easy way and the cleaner long-term approach.
What’s Going On?
Secure Boot is a UEFI firmware feature that prevents unsigned code from loading during boot. It’s a legitimate security protection — but it also means that kernel modules like VMware’s vmmon and vmnet won’t load unless they’re signed with a trusted key.
When VMware installs or rebuilds those modules, it doesn’t automatically sign them. So if Secure Boot is enabled, Linux refuses to load them, and VMware fails to start.
You can confirm this is your issue by running:
mokutil --sb-state
If it returns SecureBoot enabled, you’ve found your problem.
Option 1 — The Quick Fix: Disable Secure Boot
If you don’t have a specific reason to keep Secure Boot enabled, this is the fastest path back to a working VMware setup.
- Reboot your machine and enter your BIOS/UEFI settings (usually
F2,F10,Del, orEscon startup) - Find the Secure Boot option and disable it
- Save and boot into Linux
- Rebuild and load the VMware modules:
sudo vmware-modconfig --console --install-all
sudo modprobe vmmon
sudo modprobe vmnet
- Start VMware normally
Pros: Fast, simple, no ongoing maintenance.
Cons: You lose the security protections that Secure Boot provides.
If that trade-off is fine for your environment, you’re done. If not, read on.
Option 2 — The Right Way: Sign the Modules and Enroll a MOK
Machine Owner Keys (MOK) let you sign your own kernel modules so they’re trusted by Secure Boot. This approach keeps your security posture intact and is the recommended long-term solution.
Step 1: Install the Required Tools
On Ubuntu or Debian:
sudo apt update
sudo apt install openssl mokutil build-essential dkms linux-headers-$(uname -r)
Step 2: Generate a Signing Key
mkdir -p ~/module-signing
cd ~/module-signing
openssl req -new -x509 -newkey rsa:2048 \
-keyout MOK.priv \
-outform DER \
-out MOK.der \
-nodes -days 36500 \
-subj "/CN=VMware Module Signing/"
This creates two files:
MOK.priv— your private signing key (keep this safe)MOK.der— the public certificate you’ll enroll into the firmware
Step 3: Enroll the Key
sudo mokutil --import ~/module-signing/MOK.der
You’ll be asked to create a one-time password — remember it, you’ll need it on the next boot.
Step 4: Complete Enrollment at Boot
Reboot your machine. You’ll be presented with the MOK Manager screen. Navigate through:
- Enroll MOK
- Continue
- Yes
- Enter the password you just created
- Reboot
Step 5: Locate the VMware Module Files
modinfo -n vmmon
modinfo -n vmnet
If those commands don’t return paths yet, find them manually:
find /lib/modules/$(uname -r) -type f | grep -E 'vmmon|vmnet'
Typical paths look like:
/lib/modules/<kernel-version>/misc/vmmon.ko
/lib/modules/<kernel-version>/misc/vmnet.ko
Step 6: Sign the Modules
First, find the kernel’s signing tool:
find /usr/src/linux-headers-$(uname -r) -name sign-file
Then sign both modules:
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
~/module-signing/MOK.priv \
~/module-signing/MOK.der \
$(modinfo -n vmmon)
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
~/module-signing/MOK.priv \
~/module-signing/MOK.der \
$(modinfo -n vmnet)
If
modinfo -ndoesn’t return a path, replace$(modinfo -n vmmon)with the full path you found in Step 5.
Step 7: Load the Modules and Start VMware
sudo depmod -a
sudo modprobe vmmon
sudo modprobe vmnet
Verify they loaded:
lsmod | grep -E 'vmmon|vmnet'
Then restart VMware:
sudo systemctl restart vmware
One Important Caveat
The module signatures don’t survive automatically. If any of the following happen, you’ll need to re-sign vmmon and vmnet:
- A kernel update is installed
- A VMware update rebuilds the modules
- You manually run
vmware-modconfigagain
Keep your MOK.priv and MOK.der files in a safe location so you can re-sign quickly when needed.
Which Option Should You Choose?
| Disable Secure Boot | Sign with MOK | |
|---|---|---|
| Setup time | ~5 minutes | ~20 minutes |
| Ongoing maintenance | None | Re-sign after kernel/VMware updates |
| Security | Reduced | Maintained |
| Best for | Dev machines, home labs | Production, security-conscious setups |
Wrapping Up
VMware and Secure Boot can absolutely coexist — it just takes a bit of extra setup. If you’re running this on a personal dev box, disabling Secure Boot is a perfectly reasonable call. If you want to keep your system locked down, the MOK signing approach gives you VMware plus full Secure Boot protection.
Either way, run mokutil --sb-state first — it’ll confirm in seconds whether Secure Boot is actually the root cause before you dig deeper.
