Kernel module won't load: "insmod: ERROR: could not insert module"

Quick answer: Run modprobe --force-vermagic --force-modversion your_module to force load, but first check version magic with modinfo your_module.ko and verify dependencies with depmod -a.

You're trying to load a kernel module — maybe a custom driver, a third-party tool, or something you compiled yourself — and you get "insmod: ERROR: could not insert module". This usually pops up after a kernel update or when you try to load a module built for a different kernel version. I've seen this with NVIDIA drivers, VirtualBox modules, and custom USB devices. The message can be frustrating because it's vague. But the fix is almost always one of three things: version mismatch, missing dependencies, or bad parameters.

Step 1: Check the exact error message

Run the command again and look at the full output. For example:

sudo insmod my_module.ko

You'll see something like:

insmod: ERROR: could not insert module my_module.ko: Invalid parameters

Or maybe:

insmod: ERROR: could not insert module my_module.ko: Unknown symbol in module

Write down the exact error. I'll show you what each one means.

Step 2: Check the module's version magic

Run this:

modinfo my_module.ko | grep vermagic

You'll see a line like:

vermagic:       5.15.0-86-generic SMP mod_unload modversions

Now check your running kernel's version:

uname -r

If they don't match — for example, your kernel is 5.15.0-88-generic but the module says 5.15.0-86-generic — that's your problem. The kernel rejects the module because the version magic string is different.

What to expect: If versions match, you're good here. Move to Step 3. If they don't, the fix is to rebuild the module against your current kernel. But there's a shortcut for testing: force load (not for production).

Step 3: Fix version mismatch — rebuild the module

If you have the source, go to the module's directory and rebuild:

cd /path/to/module/source
make clean
make

After building, the new .ko file will have the correct version magic. Then try loading again:

sudo insmod my_module.ko

Expected outcome: You should see no output (success). Check with lsmod | grep my_module to confirm it's loaded.

Step 4: Check for missing dependencies

If you see "Unknown symbol in module", it means your module calls functions from other kernel modules that aren't loaded. Run:

modinfo my_module.ko | grep depends

This shows a comma-separated list of modules your module needs. For example: depends: usbcore,hid. Load those first:

sudo modprobe usbcore
sudo modprobe hid

Then try your module again. Or better, use modprobe instead of insmod — it loads dependencies automatically:

sudo modprobe my_module

Expected outcome: If dependencies are the issue, modprobe will pull them in and your module loads. If not, you'll get a clearer error.

Step 5: Check parameter errors

If you see "Invalid parameters", your module expects certain arguments that you didn't provide, or you gave the wrong ones. Check what parameters the module accepts:

modinfo -p my_module.ko

You'll see a list like:

param1: int description
param2: charp description

Load the module with the correct parameters:

sudo insmod my_module.ko param1=42 param2="some_string"

Expected outcome: No error and the module loads. Confirm with lsmod.

If the main fix doesn't work

Sometimes the kernel itself has module loading disabled. Check /proc/sys/kernel/modules_disabled:

cat /proc/sys/kernel/modules_disabled

If it shows 1, the admin has disabled module loading entirely. You can't load any modules until you set it to 0:

sudo sysctl -w kernel.modules_disabled=0

This change is temporary — it resets on reboot. To make it permanent, edit /etc/sysctl.conf and add kernel.modules_disabled=0.

Also check if Secure Boot is blocking the module. On UEFI systems, Secure Boot rejects unsigned modules. Check with:

mokutil --sb-state

If it says SecureBoot enabled, you need to sign your module or disable Secure Boot in BIOS. Signing is better for security but more complex. Disabling is quick if you're on a test machine.

Prevention tip

Always rebuild kernel modules after updating your kernel. I keep a script that runs depmod -a after each kernel update, then rebuilds modules I use regularly (VirtualBox, ZFS, custom drivers). Add the rebuild step to your update workflow. And always use modprobe instead of insmod — it handles dependencies and gives better error messages. If you're compiling your own kernel, double-check that CONFIG_MODVERSIONS and CONFIG_MODULE_SIG match between your kernel and module builds.