Load Kernel Modules service failed to start – systemd-modules-load.service

Measuring the Impact of Kernel Module Loading

To quantify the boot-time bottleneck introduced by systemd-modules-load.service, you must isolate the service's execution time from the rest of the boot sequence. On a standard Linux Mint installation, this service is typically a negligible contributor to total boot time unless a module is timing out or failing repeatedly.

Step 1: Quantify Total Service Latency

Use the systemd analyzer to determine the exact time the service took to initialize and reach a completed state:

systemd-analyze blame | grep systemd-modules-load.service

This command provides the total wall-clock time the service occupied. To see its place in the critical chain (whether it actually delayed the reach of the login screen), use:

systemd-analyze critical-chain

Step 2: Identify High-Latency Modules

Systemd does not natively log the load time of individual modules listed in /etc/modules-load.d/. To identify which specific module is responsible for latency, you must manually time the modprobe command for each entry.

1. List all configured modules: grep -r "^[^#]" /etc/modules-load.d/
2. Time the loading of a suspected module (ensure it is unloaded first if possible):

   time sudo modprobe 

Analysis of Bottlenecks

Likely Explanations:

• Missing Modules: If the service is "failed," it is often because a module listed in the config does not exist for the current kernel version (common after an update without a reboot). This causes a timeout or immediate error, which can paradoxically increase the "blame" time.
• Hardware Timeouts: Modules that attempt to initialize hardware that is physically absent or disabled in BIOS may hang for several seconds before failing.

Confirmed Facts:

• systemd-modules-load.service simply iterates through /etc/modules-load.d/ and calls modprobe.
• It does not perform hardware detection; it blindly attempts to load whatever is listed in the configuration files.

Recommendation on Conditional Loading

Adopting a hardware-aware strategy is recommended only if systemd-analyze shows this service taking more than 100-200ms. Most modules should be handled by the kernel's automatic alias detection (udev) rather than being hard-coded in /etc/modules-load.d/. If a module is required only for specific hardware, removing it from the static load list and allowing the kernel to load it on-demand is the most efficient optimization.

Diagnostic Detail Needed: Please provide the output of journalctl -u systemd-modules-load.service. If the service is failing due to a "Module not found" error, the latency is likely a result of the error-handling timeout rather than actual module initialization.