modprobe -D 仅按 modules.dep.bin 输出加载顺序，不校验文件存在性或符号可用性；运行时符号依赖需查 /proc/kallsyms；编译期符号依赖需结合 nm 和 Module.symvers 分析。
直接用 modprobe -D 查加载顺序，但别把它当“运行时依赖真相”——它只读 modules.dep.bin，不验证符号、不检查文件是否存在。
查模块加载时的依赖链：用 modprobe -D
这是唯一能直接输出 insmod 顺序的命令，适合快速确认“加载这个模块，会顺带拉哪些 .ko”。
- 执行
modprobe -D vfat，输出类似： insmod /lib/modules/6.8.0-45-generic/kernel/fs/fat/fat.koinsmod /lib/modules/6.8.0-45-generic/kernel/fs/vfat/vfat.ko-
$(uname -r)已被自动展开，不是占位符；若对应目录不存在，-D仍会输出，但后续modprobe vfat必然失败 - 它不校验
fat.ko文件是否真在路径下，也不管 Secure Boot 签名是否通过
查运行时符号是否就位：看 /proc/kallsyms
模块加载报 Unknown symbol，说明符号没导出或没加载——这时 modprobe -D 毫无帮助，得查内核当前符号表。
- 先用
sudo cat /proc/kallsyms | grep shared_func（非 root 用户看到全是 0） - 输出形如
ffffffffc1234567 t shared_func [module_a]才算有效：第二列是t或T（大写才对外可见），方括号里是提供该符号的模块名 - 如果没输出，说明
module_a没加载，或没调用EXPORT_SYMBOL（而非EXPORT_SYMBOL_GPL且依赖模块非 GPL）
查未加载模块缺哪些符号：用 nm + Module.symvers
编译阶段发现依赖问题，不能等加载失败再查——这时候要静态分析 .ko 文件本身。
- 对未加载的
module_b.ko，运行nm module_b.ko | grep "U "，列出所有U（undefined）符号，即它需要但自己没实现的函数/变量 - 这些符号是否在系统中可被满足？得结合
Module.symvers：它记录了每个导出符号来自哪个模块、属于什么许可证 - 比如
module_b.ko依赖shared_func，而Module.symvers里有0x12345678 shared_func module_a GPL，说明必须先让module_a加载且为 GPL 许可 - 手动拷贝新模块后忘了运行
sudo depmod -a，Module.symvers就不会被纳入依赖计算，modprobe -D也看不到它
真正容易被忽略的是：依赖分三层——modules.dep.bin 决定加载顺序，/proc/kallsyms 决定符号是否可见，Module.symvers 决定编译期能否链接。三者不同步，模块就卡在“看似该加载，实则加载不了”的状态。
