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.
- List all configured modules:
grep -r "^[^#]" /etc/modules-load.d/
- 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.
linuxmint