dmesg | grep -i "failed\|error" 是排查内核模块加载失败最直接的入口，因insmod/modprobe返回码无语义，真正原因全在内核环缓冲区日志中，常见错误如Unknown symbol、Invalid module format等均高频出现在dmesg最新行。
dmesg | grep -i "failed\|error" 是最直接的入口
内核模块加载失败时，insmod 或 modprobe 返回的错误码（比如 -1）本身不带语义，真正解释“为什么失败”的日志全在内核环缓冲区里。直接看 dmesg 输出，比盯着返回值有用十倍。
常见错误现象包括：Unknown symbol in module、Invalid module format、Operation not permitted、Module not found。这些字符串几乎总是出现在 dmesg 最新几行中。
- 执行
dmesg | tail -n 30查看最近的内核消息，比全量输出更聚焦 - 加
-T参数（如dmesg -T | tail -n 20）可显示带本地时间戳的日志，方便和你执行insmod的时刻对齐 - 如果刚加载完就查，但没看到报错，试试
dmesg -C清空缓冲区再重试一次，避免旧日志干扰
modinfo 和 readelf 能提前暴露兼容性硬伤
很多“加载失败”其实根本没走到符号解析那步，卡在了二进制格式或 ABI 匹配上。这时 modinfo 和 readelf 就是诊断前置条件的快检工具。
modinfo example.ko 会输出 vermagic 字段，它必须和当前内核的 uname -r 输出严格一致（包括 SMP、modversions 等修饰项）。不一致就直接触发 Invalid module format。
readelf -h example.ko 则检查 ELF 头级兼容性：
-
Machine字段必须匹配目标 CPU 架构（例如 x86_64 对应EM_X86_64） -
OS/ABI应为UNIX - System V或明确标为Linux -
Type必须是REL (Relocatable file)，不是DYN或EXEC
曾经有模块因交叉编译时误设 --target=arm-linux-gnueabihf 却跑在 x86 服务器上，readelf -h 一眼就看出 Machine: EM_ARM，省去后续所有排查。
lsmod 和 modprobe -D 揭示依赖链断裂点
Unknown symbol in module 错误几乎都源于依赖模块未加载，而不是函数写错了。这时候不能只盯着报错模块，得顺藤摸瓜看它到底缺谁。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
lsmod 列出已加载模块，确认依赖项（比如 igb 依赖 dca）是否在其中。不在？那就手动 modprobe dca 试试。
更彻底的办法是用 modprobe -D example（不加 .ko），它会打印出完整的依赖解析过程，包括每个依赖模块的路径和加载顺序。如果某一级显示 not found 或 no such file，问题就定位到了。
- 注意：模块名大小写敏感，
br_netfilter和BR_NETFILTER是两个东西 -
modprobe -D不实际加载，纯模拟，安全无副作用 - 依赖关系定义在
/lib/modules/$(uname -r)/modules.dep，可直接grep查看
systemd-modules-load.service 失败要查配置文件语法
开机时报 Failed to start Load Kernel Modules，通常不是模块本身问题，而是 /etc/modules-load.d/*.conf 里的配置写崩了。
这种失败不会在 dmesg 里报具体模块错误，而是在 systemctl status systemd-modules-load.service 的输出中提示 “configuration invalid” 或 “line XX invalid”。常见坑：
- 配置文件末尾多了一个空格或不可见字符（用
cat -A filename.conf查看） - 模块名拼错，或路径写成了绝对路径（配置里只写模块名，不带
.ko和路径） - 用了注释符
#，但前面多了空格导致被当模块名解析
修复后别忘了运行 sudo systemctl restart systemd-modules-load.service 测试，而不是等下次重启。
真正难搞的不是报错本身，而是错误信息藏在哪儿——dmesg 里可能混着几十条无关消息，modinfo 输出里 vermagic 字符串长得像乱码，modules.dep 文件又没人手动维护。把这几个命令的输出组合起来交叉验证，才能避开“以为修好了，其实只是掩盖了错误”的陷阱。
