modprobe 找不到模块通常因路径、命名或依赖错误：需确认模块在 /lib/modules/$(uname -r)/ 下，运行 depmod -a 更新依赖，检查模块名与文件名一致、内核版本匹配（vermagic）、架构正确，probe 失败时查 dmesg 错误码。
modprobe 找不到模块怎么办
模块没被 modprobe 找到，通常不是驱动没编译，而是路径、命名或依赖没对上。Linux 不会自动扫描整个文件系统找 .ko 文件，它只查 /lib/modules/$(uname -r)/ 下预建的 modules.builtin、modules.dep 和子目录结构。
- 先确认模块文件是否真在正确位置：
find /lib/modules/$(uname -r) -name "xxx.ko"（把xxx换成你的模块名） - 如果手动拷贝过模块，必须运行
depmod -a重建依赖数据库，否则modprobe完全无视它 - 模块名不等于文件名：比如
usbserial.ko的模块名是usbserial，但有些带下划线的（如8139cp.ko）加载时得写modprobe 8139cp，不能写8139-cp -
modprobe默认不看当前目录，./mymodule.ko这种路径直接报Module mymodule not found
加载时报 Invalid module format 错误
这是内核版本不匹配的典型信号——模块编译时用的内核头文件和当前运行的内核 $(uname -r) 不一致，哪怕只差一个补丁号（比如 6.1.0-12-amd64 vs 6.1.0-13-amd64）也会触发。
- 检查模块内嵌的版本信息：
modinfo ./mymodule.ko | grep ^vermagic，输出里必须和cat /proc/sys/kernel/osrelease完全一致 - 如果用 DKMS 管理，确保已执行
dkms install -m mymodule -v 1.0 --force，而不是只 build - 交叉编译的模块（如 ARM 驱动在 x86 主机上编译）即使版本对得上，也会因架构标记失败，
file mymodule.ko能看出 ELF 架构
modprobe 加载后立刻卸载（无日志、无设备节点）
模块看似加载成功（lsmod | grep xxx 能看到），但几秒后消失，大概率是 probe 失败导致内核主动回滚。这种失败默认不打 dmesg，得主动抓。
- 加
-v参数观察详细流程：modprobe -v xxx，看最后卡在哪一步（比如停在 “Running hook” 或 “Loading dependency”） - 立即执行
dmesg | tail -20，重点找xxx: probe of xxx failed with error -XX，常见错误码：-19（-ENODEV，没找到对应硬件）、-22（-EINVAL，参数错）、-16（-EBUSY，资源被占） - 某些模块（如
hid_generic）依赖其他模块先加载，modprobe --show-depends xxx可验证依赖链是否完整
如何让模块开机自动加载
写进 /etc/modules 最简单，但它不处理参数和顺序；更可靠的方式是用 /etc/modprobe.d/ 下的配置文件。
- 要传参数（比如
blacklist nouveau或options iwlwifi swcrypto=1），必须用/etc/modprobe.d/my.conf，格式严格：options <module_name><key>=<value></value></key></module_name> -
blacklist不等于卸载，只是阻止modprobe自动加载；已内置的模块（modules.builtin）无法用 blacklist 屏蔽 - 如果模块依赖固件（
.bin文件），确保固件放在/lib/firmware/对应路径下，否则加载会卡住并超时退出
真正麻烦的是那些 probe 阶段需要特定 PCI ID、ACPI 表或平台设备才肯活的模块——它们可能在 initramfs 里就该加载，而不是等根文件系统挂载后。这点容易被忽略，一重启就回退成“模块存在但设备没出来”。
