How to Fix “Failed to Start Load Kernel Modules” in Ubuntu

The systemd boot warning “Failed to start Load Kernel Modules” (associated with systemd-modules-load.service) occurs during Ubuntu startup when the kernel module loader encounters an entry in /etc/modules or /etc/modules-load.d/ referencing a driver, file system module, or hardware extension that cannot be found or fails to compile against the currently running Linux kernel version. While Ubuntu often continues booting to the desktop despite this error, missing modules can disable virtualization features (KVM), hardware acceleration, or proprietary peripherals. Resolving this issue involves diagnosing which module is failing, cleaning obsolete configuration entries, and rebuilding DKMS modules.

Understanding systemd-modules-load.service in Ubuntu

During the early boot phase, systemd-modules-load.service scans declarative configuration directories—specifically /etc/modules-load.d/*.conf, /run/modules-load.d/*.conf, and the legacy /etc/modules file. It attempts to load each listed module into kernel space using the modprobe utility. If even a single listed module fails to load (due to syntax errors, uninstalled packages, or kernel ABI incompatibilities), systemd flags the entire service as Failed.

Common culprits include:

• Obsolete Kernel Modules After Updates: Third-party modules compiled for an older kernel release that failed to rebuild via DKMS (Dynamic Kernel Module Support) during a kernel upgrade.
• Uninstalled Virtualization Tools: Lingering module entries for VirtualBox (vboxdrv), VMware, or proprietary hardware that were partially uninstalled.
• Typographical Errors in Configuration Files: Manual edits to /etc/modules containing misspelled module names. For associated startup timeouts, see our guide on fixing A stop job is running slow shutdown in Ubuntu.
• Blacklisted Modules: A module explicitly listed in /etc/modules that is simultaneously blocked within /etc/modprobe.d/blacklist.conf.

Configuration Directory	Priority Level	Intended Use Case
/etc/modules-load.d/*.conf	High (Administrator)	Custom local static module loading directives
/etc/modules	Legacy / High	Debian/Ubuntu classic static module list
/run/modules-load.d/*.conf	Transient / Runtime	Dynamic module configurations generated during boot
/usr/lib/modules-load.d/*.conf	Package Default	System package default module directives

Step 1: Identify the Specific Module Causing the Service Failure

To fix the error, you must identify which exact module is failing to load:

1. Open your terminal application by pressing Ctrl + Alt + T.
2. Check the status and log output of the module loader service:

systemctl status systemd-modules-load.service

3. Review the journal logs to see the precise error message:

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

4. Look for lines marked in red or warnings stating:

Failed to insert 'module_name': No such file or directory
Failed to find module 'module_name'

Note the exact name of the failed module (e.g., vboxdrv, lp, or fuse).

Step 2: Inspect and Clean Static Module Directives

Once you know the failing module’s name, locate where it is declared and remove or comment out the orphaned entry.

1. Check the contents of the primary /etc/modules file:

cat /etc/modules

2. If the failing module is listed, edit the file using administrative privileges:

sudo nano /etc/modules

3. Place a hash symbol (#) in front of the offending module name to comment it out, or delete the line completely. Press Ctrl + O and Enter to save, then Ctrl + X to exit.
4. Check for custom configuration files inside /etc/modules-load.d/:

ls -la /etc/modules-load.d/

5. Inspect any .conf files in that directory using cat /etc/modules-load.d/<filename>.conf. If you find the broken module reference, edit the file and remove the entry.

Step 3: Rebuild Dynamic Kernel Modules via DKMS

If the missing module is a legitimate driver (such as VirtualBox guest additions, proprietary Wi-Fi drivers, or NVIDIA modules) that failed during a recent kernel update, rebuilding DKMS restores the binary.

1. Verify which kernel version is currently active:

uname -r

2. Ensure that your system possesses the necessary kernel development headers:

sudo apt update
sudo apt install build-essential linux-headers-$(uname -r) dkms

3. Rebuild all registered DKMS modules against your current kernel:

sudo dkms autoinstall

This compiles the kernel object files (.ko) and places them in /lib/modules/$(uname -r)/updates/dkms/.

Step 4: Update the Initial RAM Filesystem (initramfs)

After adjusting kernel modules, regenerate the initramfs image to ensure the changes take effect from the earliest stages of boot.

1. In the terminal, run the initramfs update tool:

sudo update-initramfs -u -k all

Wait for the command to regenerate the boot images for all installed kernel versions.

Step 5: Restart and Verify the Service Status

Test the module loading service immediately without needing a full system reboot:

1. Restart the service using systemctl:

sudo systemctl restart systemd-modules-load.service

2. Check the status again:

systemctl status systemd-modules-load.service

The service should now display as Active: active (exited) with a green indicator, confirming that all declared modules loaded cleanly into kernel memory.