“Invalid module format”是因内核版本或符号版本不匹配，需检查modinfo输出与uname -r是否一致、编译是否使用正确内核头文件及Module.symvers；lsmod中星号表示模块tainted；insmod后未列显但无错，多因init函数返回非零值，应查dmesg；推荐用modprobe替代insmod以自动处理依赖和配置。
insmod 加载模块时提示 “Invalid module format” 怎么办
这通常不是权限问题，而是内核版本或符号版本不匹配。模块编译时用的 KBUILD_EXTRA_SYMBOLS 或 Module.symvers 文件缺失、路径不对，或者模块没用当前运行内核的头文件编译。
- 检查模块依赖的内核版本：
modinfo
，输出应与your_module.ko| grep ^vermagicuname -r完全一致（包括-smp、-generic等后缀） - 确认编译环境使用了正确的内核源码树，比如：
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules - 若模块引用了外部符号，确保
Module.symvers在构建目录中且被正确引用 - 禁用签名强制（仅调试）：加载时加
insmod your_module.ko sig_id=0（需内核配置支持CONFIG_MODULE_SIG_FORCE=n）
lsmod 输出里模块名后面带星号（*）代表什么
星号表示该模块已被标记为“tainted”，即内核认为其来源不可信或行为可能影响稳定性。常见触发条件包括：模块未签名、使用了 staging 驱动、调用了 EXPORT_SYMBOL_GPL 以外的非 GPL 符号、或在加载时绕过了签名验证。
-
lsmod本身不显示 taint 状态细节，要看dmesg或/proc/sys/kernel/tainted的数值 - 数值非零即 tainted，可用
cat /proc/sys/kernel/tainted | awk '{printf \"%x\\n\", $1}'查对应标志位 - 星号不影响模块功能，但某些厂商驱动或调试工具会拒绝在 tainted 内核上运行
insmod 后模块没出现在 lsmod 列表中，但也没报错
最可能是模块初始化函数（module_init()）返回了非零值，导致加载失败并自动卸载。这种失败不会向终端打印明显错误，只记入内核日志。
- 立即执行
dmesg | tail -20，查找类似your_module: init failed with -22的行 - 检查
init函数是否调用了request_irq()、register_chrdev()等可能失败的接口，并做了错误处理和返回 - 模块中若有
__init段函数，在初始化完成后会被释放，无法通过cat /sys/module/your_module/sections/.init.text查看 —— 这是正常行为，不代表加载失败 - 确认模块没有被
modprobe的黑名单机制拦截（检查/etc/modprobe.d/*.conf中是否有blacklist your_module）
为什么不用 insmod 而改用 modprobe
insmod 是底层加载器，不做依赖解析、别名展开或参数预设；modprobe 才是日常管理的合理入口。直接用 insmod 绕过依赖检查，容易导致模块静默失效或系统不稳定。
-
modprobe your_module会自动加载your_module.ko及其所有depends:字段声明的依赖模块 - 支持配置：可在
/etc/modprobe.d/下写options your_module debug=1，下次modprobe时自动传参 -
insmod必须指定完整路径（如insmod ./your_module.ko），而modprobe从/lib/modules/$(uname -r)/下搜索，更安全可靠 - 调试时才用
insmod：比如测试未安装到标准路径的开发版模块，或复现特定加载顺序问题
模块加载不是“执行完就完事”，init 函数的返回值、符号解析时机、内核版本字符串的每个字符，都可能让一切静默失败。别只盯着命令是否报错，dmesg 和 modinfo 才是真实信源。
