modprobe -D 是唯一能直接输出模块完整依赖链的命令，它读取 modules.dep.bin 并按 insmod 顺序打印路径，但不验证模块存在性、内核兼容性或签名；需先运行 depmod -a 生成依赖文件，否则输出为空或报错。
modprobe -D 能直接打印依赖加载顺序，但不验证模块是否存在
modprobe -D 是唯一能直接输出模块依赖链的命令，它读取 modules.dep.bin 文件，按 insmod 所需顺序逐行打印路径。比如：
modprobe -D vfat
会输出：
insmod /lib/modules/$(uname -r)/kernel/fs/fat/fat.ko insmod /lib/modules/$(uname -r)/kernel/fs/vfat/vfat.ko
注意三点：
-
modprobe -D不检查.ko文件是否真实存在，也不校验内核版本兼容性，只做静态路径拼接 - 输出中的
$(uname -r)是实际展开后的内核版本号（如6.8.0-45-generic），不是占位符；若对应目录在/lib/modules/下缺失，命令仍可能成功，但后续加载必失败 - 它只反映“理论依赖”，不等于模块一定能加载成功——比如
fat.ko缺失或签名未通过 Secure Boot，modprobe -D照样输出，但modprobe vfat会报Module fat not found或Operation not permitted
depmod -a 必须先运行，否则 modprobe 找不到依赖
如果 modprobe -D 输出为空、或提示 Module xxx not found，大概率是 modules.dep.bin 没生成或已过期。这时要手动触发依赖重建：
sudo depmod -a
这个动作扫描 /lib/modules/$(uname -r)/ 下所有 .ko 文件，分析 MODULE_INFO(depends, "...") 和符号导出关系，生成或更新：
-
/lib/modules/$(uname -r)/modules.dep（文本格式） -
/lib/modules/$(uname -r)/modules.dep.bin（二进制格式，modprobe实际读取的文件）
常见漏掉的场景：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 手动拷贝新模块到
/lib/modules/$(uname -r)/后没运行depmod -a - 升级内核后仍用旧版
depmod处理新模块目录（应指定版本：sudo depmod -a 6.8.0-45-generic） - 使用
depmod -n查看依赖时误以为已写入磁盘——它只是模拟输出，不落地
查某个模块到底依赖谁？别只信 modinfo -d
modinfo -d 显示的是作者写的描述文字，不是真实依赖。真正反映依赖的是：
-
modinfo -F depends <module_name>：读取模块 ELF 段里的depends字段（如vfat返回fat） -
grep "^/lib/modules/.*<module_name>.ko:" /lib/modules/$(uname -r)/modules.dep：直接查modules.dep中该模块所在行，右边列出的就是它的直接依赖 -
modprobe -D <module_name>：从根模块开始，递归展开整个加载链（包括间接依赖）
例如：
modinfo -F depends vfat # 输出：fat grep "^/lib/modules/.*vfat.ko:" /lib/modules/$(uname -r)/modules.dep # 输出：.../vfat.ko: .../fat.ko
这两者结果一致，但 modprobe -D vfat 还会继续展开 fat.ko 的依赖（比如 libcrc32c），这才是完整链。
依赖关系错乱时，dmesg 比 modprobe 报错更准
当 modprobe xxx 失败，错误信息往往很模糊：
-
FATAL: Module xxx not found→ 先确认modprobe -l | grep xxx是否列出了该模块，再检查find /lib/modules/$(uname -r) -name "xxx.ko*" -
Operation not permitted→ 几乎肯定是 Secure Boot 阻止了未签名模块，不是权限问题；用mokutil --list-enrolled看是否启用，或临时关 Secure Boot 测试 - 加载成功但功能异常（比如 USB 设备不识别）→
dmesg | tail -20才是关键，里面会有usbcore: invalid parameter或xxx: probe failed这类真实初始化错误
依赖本身没问题，但模块参数错、硬件不匹配、内核 ABI 不兼容，这些都藏在 dmesg 里，modprobe 命令层面根本不会告诉你。
