How to Fix VMware Module Errors When Secure Boot Is Enabled on Linux

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.

1. Reboot your machine and enter your BIOS/UEFI settings (usually F2, F10, Del, or Esc on startup)
2. Find the Secure Boot option and disable it
3. Save and boot into Linux
4. Rebuild and load the VMware modules:

sudo vmware-modconfig --console --install-all
sudo modprobe vmmon
sudo modprobe vmnet

5. 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:

1. Enroll MOK
2. Continue
3. Yes
4. Enter the password you just created
5. 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 -n doesn’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-modconfig again

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.