systemd-modules-load.service失败源于配置文件中指定的模块（如usbserial、ftdi_sio）缺失或不可加载，需通过systemctl status和journalctl定位具体模块，再检查/etc/modules-load.d/下的.conf文件并验证模块是否存在。
直接看 systemd-modules-load.service 的失败详情
报错 Failed to start Load Kernel Modules 时，真正出问题的是 systemd-modules-load.service。它不负责加载所有模块，只按配置文件（/etc/modules-load.d/*.conf 和 /usr/lib/modules-load.d/*.conf）逐行执行 modprobe。失败原因不会直接显示在启动画面里，必须查服务状态和日志。
运行以下命令获取第一手线索：
-
systemctl status systemd-modules-load.service -n 100—— 查看最近 100 行输出，重点看Process:行调用的modprobe命令及退出码（如status=1或status=255） -
journalctl -u systemd-modules-load.service -b --no-pager—— 完整回放本次启动中该服务的所有日志，包括modprobe报的具体错误字符串 -
cat /etc/modules-load.d/*.conf /usr/lib/modules-load.d/*.conf 2>/dev/null | grep -v '^#' | grep -v '^$'—— 确认实际被加载的模块列表，避免空行或注释干扰判断
定位具体是哪个模块加载失败
配置文件里每行一个模块名，systemd-modules-load.service 是顺序执行的，失败即中断，后续模块不会尝试加载。所以日志里最后成功加载的模块，就是失败模块的前一个。
常见失败模块类型包括：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 拼写错误：比如写了
radeon但当前内核只提供amdgpu（注意大小写敏感） - 模块已废弃：如旧版
ip_tables在较新内核中被nf_tables替代，modprobe ip_tables会返回Module ip_tables not found in directory /lib/modules/$(uname -r) - 依赖缺失：例如
igb模块依赖dca，而dca未被提前加载或根本不存在 - 硬件不匹配：某些安全模块（如
tpm_tis、ima_policy）在无对应硬件或 BIOS 中禁用 TPM 时会静默失败，但modprobe仍返回非零退出码
验证模块是否存在且可加载
不要只信配置文件，手动验证才是关键。对日志中疑似失败的模块名（比如 evm、ima、tpm），逐个执行：
-
find /lib/modules/$(uname -r) -name "*evm*.ko*" 2>/dev/null—— 看模块文件是否物理存在 -
modinfo evm 2>/dev/null | grep -E '^(vermagic|depends|alias)'—— 检查模块兼容性（vermagic必须匹配当前内核）、依赖项（depends）和别名（alias） -
sudo modprobe -v evm—— 加-v参数让modprobe显示详细加载路径和依赖解析过程，能暴露Unknown symbol in module或Operation not permitted等底层错误 -
lsmod | grep -E '^(evm|ima|tpm)'—— 确认是否已被其他机制（如内核内置、initramfs 阶段）提前加载，此时再由modules-load加载会因重复而失败
安全模块特有的坑：initramfs 和内核编译选项
像 ima、evm、tpm_tis 这类模块，往往不是单纯“加载失败”，而是受制于更底层条件：
- 它们可能被编译进内核（
CONFIG_IMA=y），而非以模块形式存在（CONFIG_IMA=m）。此时modprobe ima必然失败，因为没有.ko文件 - 某些发行版（如 RHEL/CentOS）把
ima相关策略写在 initramfs 里，启动早期就生效；如果/etc/modules-load.d/ima.conf又试图加载，反而触发冲突 -
tpm_tis在 BIOS 中关闭 TPM 或启用 PTT（Intel Platform Trust Technology）但驱动未适配时，modprobe tpm_tis可能卡住数秒后超时退出，日志只显示timeout而非明确原因 - SELinux 策略若限制了
modprobe访问/lib/modules/下某些路径，也会导致Operation not permitted，需查ausearch -m avc -ts recent
真正难啃的点往往不在模块本身，而在它和内核配置、initramfs、硬件固件之间的隐式耦合。看到 status=1 别急着删配置，先确认它是“找不到模块”还是“拒绝加载”。
