modprobe -D 是唯一能直接输出模块完整 insmod 加载顺序的命令，它基于 modules.dep.bin 静态解析，不校验 .ko 文件是否存在、内核版本是否匹配或 Secure Boot 签名是否通过；需先运行 depmod -a 生成依赖文件，否则命令失效。
modprobe -D 能直接看到依赖加载顺序，但不验证文件是否存在
查某个模块加载时会拉哪些 .ko 文件，modprobe -D 是唯一能直接输出完整 insmod 顺序的命令。它读的是 /lib/modules/$(uname -r)/modules.dep.bin，纯静态解析，不检查路径下是否有对应 .ko 文件，也不管内核版本是否匹配。
比如查 vfat 模块：modprobe -D vfat
输出类似：
insmod /lib/modules/6.8.0-45-generic/kernel/fs/fat/fat.ko insmod /lib/modules/6.8.0-45-generic/kernel/fs/vfat/vfat.ko
-
$(uname -r)已被实际展开，不是占位符；你要确认/lib/modules/6.8.0-45-generic/目录真实存在 - 拼错模块名（如写成
vfatx）或fat.ko缺失，modprobe -D仍可能成功输出——它根本不校验文件 - 这个顺序就是
modprobe vfat实际执行的加载链，但不代表一定能成功加载：比如fat.ko被 Secure Boot 拒绝，modprobe -D看不出
depmod -a 必须先跑，否则 modprobe -D 会失效或报错
modprobe -D 依赖 modules.dep.bin，而这个文件由 depmod 生成。如果你刚手动放了一个新 .ko 文件进去，或者换了内核但没重建依赖，modprobe -D 就会输出为空、或提示 Module xxx not found。
修复方法只有一条：sudo depmod -a
- 它扫描
/lib/modules/$(uname -r)/下所有 .ko，分析MODULE_INFO(depends, "")和符号导出关系 - 同时更新两个文件：
modules.dep（文本）和modules.dep.bin（modprobe 实际读取的二进制格式） - 注意：
depmod不会自动运行，系统升级内核后常遗漏这步，导致后续所有modprobe命令行为异常
lsmod 只显示已加载模块的引用关系，看不出“谁依赖谁”的方向
lsmod 输出第三列是 “used by”，比如这一行：nvidia 26214400 87 nvidia_uvm,nvidia_drm
意思是 nvidia 模块被 nvidia_uvm 和 nvidia_drm 依赖——但这个信息是反向的：它告诉你“谁在用我”，而不是“我要先加载谁”。
- 想确认
nvidia_uvm是否依赖nvidia，不能靠lsmod，得用modprobe -D nvidia_uvm -
lsmod | grep nvidia可能漏掉nvidia_modeset这类名字变体，更稳妥的是lsmod | awk '{print $1}' | grep -E '^nvidia' - 第三列数字为 0 不代表模块空闲；只要设备还在用（比如 GPU 正在渲染），
rmmod nvidia仍会失败，此时要看dmesg | tail
符号级依赖要查 /proc/kallsyms，不是 modules.dep.bin
模块加载报 Unknown symbol in module，说明运行时符号找不到。这时候 modprobe -D 和 depmod 都帮不上忙，因为它们只管模块文件层级的依赖，不管函数/变量级别的导出与引用。
真正反映当前内核里符号状态的，只有：sudo cat /proc/kallsyms | grep shared_func
- 输出形如
ffffffffc1234567 t shared_func [module_a]才算有效：第二列必须是大写T（函数）或D（已初始化变量），小写t/d是局部符号，其他模块不可见 - 非 root 用户看到的地址全是
0000000000000000，必须加sudo -
EXPORT_SYMBOL_GPL导出的符号，若加载模块许可证不是 GPL，即使出现在/proc/kallsyms中也会加载失败
modprobe -D）、编译期符号引用（nm *.ko | grep U + Module.symvers）、运行时符号可见性（/proc/kallsyms）。多数人只查第一层，问题卡住时才发现后两层才是关键。 
