modprobe找不到模块最常见原因是模块未放入/lib/modules/$(uname -r)/kernel/对应子目录且未执行sudo depmod -a更新依赖数据库，导致modprobe无法扫描和识别该模块。
内核模块加载不是“配置完就自动生效”的事，必须明确区分「手动加载」「开机自动加载」和「按需触发加载」三种场景，否则容易漏掉关键环节导致模块不工作。
modprobe 为什么找不到你的模块
最常见的情况是 modprobe 报错 Module xxx not found in directory /lib/modules/$(uname -r)。这不是命令用错了，而是模块根本没放进标准路径。
- 模块文件（
.ko）必须放在/lib/modules/$(uname -r)/kernel/下的某个子目录里（如drivers/net/、fs/），不能只丢在当前目录或/tmp - 放好后必须运行
sudo depmod -a，否则modprobe不会扫描新模块，也不会生成依赖映射表 - 如果模块有自定义命名空间（比如用了
MODULE_IMPORT_NS），还要确保依赖的命名空间已导出，否则modprobe会静默失败
开机自动加载模块的真正写法
很多人直接往 /etc/modules 里写模块名就以为搞定了，但实际可能被 initramfs 忽略，或因依赖顺序错乱而失败。
-
/etc/modules只在 rootfs 挂载后由 systemd-modules-load.service 加载，适合无依赖的简单模块 - 若模块依赖其他模块（比如
usbserial依赖usbcore），必须用modprobe.d配置文件控制顺序：/etc/modprobe.d/xxx.conf中写softdep module_name pre: dep_module - 需要在 initramfs 阶段加载的模块（如磁盘加密驱动
dm-crypt），得额外执行sudo update-initramfs -u（Debian/Ubuntu）或sudo dracut -f（RHEL/Fedora）
insmod 和 modprobe 的关键区别别踩坑
用 insmod 成功不代表 modprobe 能行，反过来也一样——它们走的是完全不同的加载路径。
-
insmod /path/to/module.ko绕过所有依赖检查和路径搜索，只做最基础的内核插入，适合调试阶段快速验证模块能否编译通过 -
modprobe module_name会查/lib/modules/$(uname -r)/modules.builtin、modules.alias、modules.dep三层映射，缺一不可 -
insmod加载的模块无法被modprobe -r卸载，因为没注册进模块数据库；必须用rmmod module_name，且模块名得和MODULE_LICENSE里声明的一致
模块参数传递和验证方式
光加载成功还不够，很多模块靠参数才能启用功能，而参数传错不会报错，只会静默失效。
- 模块参数在
module_param()定义，加载时用modprobe module_name param=value传入，注意 value 类型要匹配（bool/int/charp） - 确认参数是否生效：查看
/sys/module/module_name/parameters/下对应文件内容，或用modinfo module_name看参数说明 - 如果模块支持多实例（如
dummy），重复加载时要用modprobe module_name name=eth1显式指定实例名，否则第二个会失败
真正的难点不在语法，而在模块是否被内核信任、依赖是否完整、参数是否被正确解析——这些都不会在终端里直接告诉你，得去 dmesg 里逐行翻错误线索。
