Fix kernel module version mismatch in Linux

Quick answer

Run sudo dkms install -m <module> -v <version> -k $(uname -r) or reinstall the kernel-headers package matching your running kernel, then rebuild.

What's happening

You get an error like Invalid module format or Exec format error when you run modprobe or insmod. The kernel checks a version magic string inside every module — if it doesn't match the running kernel's version, it refuses to load. This usually happens after a kernel update. You installed a new kernel (say 5.15.0-100), but the module was compiled for 5.15.0-92. The kernel doesn't care if they're close — it's a strict string match. The culprit here is almost always a system update that didn't rebuild external modules.

Real-world trigger

I see this most often on Ubuntu or Debian servers after running apt upgrade that includes a new kernel, but the DKMS rebuild fails silently. Or on CentOS/RHEL after yum update kernel — third-party drivers like NVIDIA or ZFS break.

Fix steps (try this first)

Check your running kernel version
```
uname -r
```
Verify the module's version magic
```
modinfo <module_name> | grep vermagic
```
Compare this output to uname -r. If they differ, you've found the problem.
Rebuild using DKMS
```
sudo dkms status
```
This lists all DKMS-managed modules. If yours is there but not built for the current kernel:
```
sudo dkms build -m <module_name> -v <version> -k $(uname -r)
sudo dkms install -m <module_name> -v <version> -k $(uname -r)
```
Find the version from the status output.

If DKMS isn't available, reinstall the kernel headers

sudo apt install linux-headers-$(uname -r)   # Debian/Ubuntu
sudo yum install kernel-devel-$(uname -r)    # RHEL/CentOS

Manually rebuild the module
For modules from source (not DKMS), go to the source directory and run:
```
make clean
make
sudo make modules_install
```
This recompiles against the current kernel headers.
Update module dependencies
```
sudo depmod -a
```
Try loading again
```
sudo modprobe <module_name>
```

Alternative fixes if the main one fails

Force ignore the version check (not recommended for production)
You can pass modprobe.force_modversion=1 as a kernel boot parameter. This skips the version magic check. It'll load the module, but you risk crashes if the kernel ABI changed. Only use this for testing.
```
echo 'options modprobe force_modversion=1' | sudo tee /etc/modprobe.d/force-modversion.conf
```
Then reboot.
Reboot into the previous kernel
If you need the module working now and can't rebuild, pick the older kernel from GRUB menu. Edit /etc/default/grub and set GRUB_DEFAULT=saved, then run sudo update-grub.
If it's a built-in kernel module (like a filesystem)
This is rare — built-in modules are part of the kernel image. You'll need to rebuild the whole kernel with make localmodconfig and install it. Skip this unless you're building custom kernels.
Check for stale .ko files in /lib/modules
```
find /lib/modules/$(uname -r) -name '*.ko' -exec modinfo {} \; | grep -E 'vermagic|filename'
```
Sometimes leftover modules from a botched install linger. Remove them with rm.

Prevention tip

Install dkms before updating kernels. On Debian/Ubuntu:

sudo apt install dkms

On RHEL/CentOS:

sudo yum install dkms

Then for every third-party module you install, register it with DKMS. For example, for the ZFS module:

sudo dkms add /path/to/zfs-source

After a kernel update, run sudo dkms autoinstall to rebuild everything automatically. This catches the mismatch before you reboot.

Also, pin your kernel version if you're in a production environment. On Ubuntu, hold the kernel package:

sudo apt-mark hold linux-image-$(uname -r)

But that's a band-aid — real fix is DKMS.