内核更新编译后驱动模块加载报错：版本魔法不匹配及invalid module format

Let’s break down what’s happening here first: when you modified kernel parameters and compiled a new kernel image, the kernel automatically appended a git hash (-ge82bfab) and a dirty flag to the version string—this happens due to uncommitted changes or git repo context during compilation. This creates a mismatch between your running kernel’s version magic (4.9.0-00011-ge82bfab-dirty) and the clean 4.9.0 string modules are compiled against. Both old pre-built modules and new modules compiled with mismatched kernel headers/configs will fail to load as a result.

Here are the step-by-step solutions to resolve this:

1. Compile Modules Against the Correct Custom Kernel Headers/Source #

This is the proper, long-term fix for compatibility:

• First, confirm your running custom kernel’s full version with:

  uname -r
  

  You should see 4.9.0-00011-ge82bfab-dirty as output.
• When compiling your new module, update its Makefile to point directly to your custom kernel’s source directory (or the installed headers path). Example Makefile:

  obj-m += my_driver.o
  # Replace with your actual custom kernel source path
  KDIR := /home/your-user/linux-4.9-custom
  PWD := $(shell pwd)
  
  all:
      $(MAKE) -C $(KDIR) M=$(PWD) modules
  clean:
      $(MAKE) -C $(KDIR) M=$(PWD) clean
  

• If you installed your custom kernel’s headers via make modules_install and make install during kernel compilation, you can also use the system-installed headers path instead:

  KDIR := /lib/modules/$(shell uname -r)/build
  

• Recompile your module with this updated Makefile—it will now generate a module with the matching version magic string.

2. Standardize the Kernel Version String (Optional) #

If you want your custom kernel to use the clean 4.9.0 version string (no git hash/dirty flag), modify the kernel source’s root Makefile:

• Open /path/to/custom-kernel/Makefile
• Locate these lines:

  VERSION = 4
  PATCHLEVEL = 9
  SUBLEVEL = 0
  EXTRAVERSION = -00011-ge82bfab-dirty
  

• Set EXTRAVERSION to an empty string, or remove any git-related auto-generation logic (like $(shell git describe ...) that might be populating it)
• Recompile and reinstall the kernel and modules:

  make clean && make -j$(nproc) && make modules_install && make install
  

• Reboot into the new kernel—uname -r will now show 4.9.0, and modules compiled against the original 4.9.0 headers will work (though compiling against the custom source is still recommended).

3. Recompile Old Modules for the Custom Kernel #

For your existing old driver modules:

• Grab the source code for those modules (if you don’t have it, retrieve it from the original kernel source or driver provider)
• Use the same Makefile setup from step 1 to compile them against your custom kernel’s source/headers. This will generate modules with the correct version magic that load without errors.

4. Force Module Loading (Testing Only!) #

⚠️ Do NOT use this in production—it bypasses kernel version checks and can cause system crashes or instability. For temporary testing, you can force-load the module with:

insmod --force-modversion your_module.ko
# Or with modprobe:
modprobe --force your_module

Key Notes #

• Ensure your kernel was compiled with CONFIG_MODVERSIONS enabled (this is the default in most cases) to enforce module version compatibility checks. Disabling it removes the checks but is not recommended.
• Always use the same compiler and compilation flags for modules that were used to build your custom kernel (e.g., if you used an aarch64 cross-compiler for the kernel, use the same one for modules).

内容的提问来源于stack exchange，提问作者Itzik Chaimov