GNU/Linux内核模块加载失败求助：systemd服务启动异常

碰到这个内核模块加载失败的问题，咱们先从最关键的日志信息入手，一步步定位问题：

第一步：获取详细错误日志 #

先运行这条命令查看服务失败的具体原因，这是排查的核心：

journalctl -u systemd-modules-load.service -xe

这条命令会输出服务启动过程中的完整日志，里面会明确告诉你是哪个模块加载失败、失败的具体原因（比如模块不存在、依赖缺失、内核不兼容等）。

第二步：根据日志针对性排查 #

1. 检查配置文件中的模块有效性 #

systemd-modules-load 会从两个目录加载模块配置：/etc/modules-load.d/ 和 /usr/lib/modules-load.d/。先列出所有配置文件：

ls -l /etc/modules-load.d/ /usr/lib/modules-load.d/

逐个打开这些文件，确认里面的模块名有没有拼写错误。之后用 modinfo <模块名> 验证模块是否存在于当前内核中——如果返回 modinfo: ERROR: Module xxx not found.，说明模块未安装、名字错误或者当前内核不支持该模块。

2. 检查模块依赖关系 #

部分模块需要依赖其他模块才能正常加载，用这条命令查看目标模块的依赖：

modprobe --show-depends <模块名>

如果依赖的模块未加载或不存在，也会导致当前模块加载失败，需要先解决依赖问题。

3. 验证内核版本兼容性 #

如果刚升级过内核，第三方模块（比如显卡驱动、虚拟网卡、硬件适配模块等）可能还没适配新内核。先查看当前内核版本：

uname -r

然后检查第三方模块是否有对应内核版本的安装包，或者重新编译模块适配新内核。

4. 临时禁用可疑模块 #

如果日志明确指出某个模块导致失败，可以先临时注释掉配置文件中该模块的行，然后重启服务测试：

systemctl restart systemd-modules-load.service

如果服务能正常启动，就说明是这个模块的问题，再针对性修复（比如重新安装模块、更换兼容版本）。

5. 修复损坏的配置文件 #

如果配置文件存在语法错误（比如多余符号、格式混乱），也会导致服务加载失败。检查每个配置文件，确保每行只写一个模块名，没有无效内容。

最后 #

如果以上步骤都没解决问题，把 journalctl -u systemd-modules-load.service -xe 的完整输出贴出来，就能更精准地定位并解决问题了。

内容的提问来源于stack exchange，提问作者Danrley Pereira