A "Start job is running for Load Kernel Modules" line that hangs your boot means systemd-modules-load.service is stuck waiting on a module that either doesn't exist, doesn't match your running kernel, or is wedged partway through hardware init. Don't wait it out and don't blindly mask the service. Read the logs, find the exact module name, and fix why it fails to load. Suppressing the symptom just moves the failure somewhere less obvious.

Last updated: 2026-07-21

This error scares people more than it should. It happens a lot, and it's fixable once you know where to look. The trick is reading what the system already told you instead of guessing.

What the message actually means

It means one systemd unit, systemd-modules-load.service, is blocking your boot while it tries to insert modules it was told to load early. Kernel modules are code that extends the kernel's functionality without needing a reboot. Think hardware drivers, filesystem support, or networking protocols. When one of those won't insert, the service sits and waits.

That unit reads its instructions from a few plain-text files: /etc/modules-load.d/, /run/modules-load.d/, and /usr/lib/modules-load.d/. Each line names a module to load at boot. If a listed module is missing, misnamed, or incompatible with your kernel, the load fails and the boot job stalls until systemd's timeout fires.

So the message isn't vague. It points at one service, and that service points at one file full of module names. The systemd-modules-load.service documentation spells out exactly which paths it reads. Your job is to find which name on those lines is the problem.

How do you find which kernel module is causing the delay?

Run this first, once you reach a shell:

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

That scopes the log to the current boot and to the one unit that is failing. Read the actual lines. You'll usually see Failed to find module 'foo' or could not insert 'bar': Exec format error. That name is your suspect. Everything else is noise.

Next, ask systemd where the boot time went:

systemd-analyze blame
systemd-analyze critical-chain

If the module service ate 90 seconds, blame shows it near the top. critical-chain shows whether it actually held up the rest of boot or just ran alongside it. That tells you whether you are chasing a real blocker or a slow unit you can ignore.

Then check the kernel ring buffer for the driver's own complaint:

sudo dmesg -T | grep -i -e module -e error

The kernel logs the real reason a module refused to insert: a version mismatch, a missing symbol, hardware that never answered. Read the last few lines before you touch anything. Nine times out of ten the answer is already printed and people scroll right past it.

Delay versus outright failure

These are two different states and they want different fixes. A delay means the service eventually succeeds or times out and boot continues. An outright failure means the unit enters a failed state and, depending on your setup, drops you to an emergency shell.

systemd-modules-load.service has a start timeout. When a module load hangs on hardware that never initializes, the service waits the full timeout before giving up. That's the 90-second-ish pause people describe. It isn't frozen; it's counting down.

Here is how to tell which one you have:

Match your symptom before you start editing files. Fixing a timeout like it's a hard failure wastes an evening.

Fixing the failed load, step by step

Work from the log, not from a forum thread. Here is the order I use.

1. Find the module. Run journalctl -b -u systemd-modules-load.service and read the failing name straight from the output. Don't skip this. Every step below depends on knowing the exact module.

2. Confirm it exists for your kernel. Run modinfo <module>. If modinfo says the module isn't found, the file is missing for your running kernel, not corrupt. That's a different problem from a module that exists but won't insert.

3. Load it by hand and read the error. sudo modprobe <module> reproduces the failure in the open. Exec format error means a kernel version mismatch. Unknown symbol means a dependency or ABI problem. No such device means the hardware isn't there and the entry probably shouldn't be forcing the load at all.

4. Rebuild if it's a DKMS module. DKMS (Dynamic Kernel Module Support) is the standard tool most Linux systems use to rebuild modules automatically when a new kernel is installed. If a build got skipped, run sudo dkms autoinstall, then reboot and recheck the log.

5. Fix the config file if the name is wrong or stale. Open the offending file under /etc/modules-load.d/ and correct or remove the bad line. A module that no longer exists in your kernel has no business being force-loaded at boot.

Each command tells you something specific. modprobe's exit code and message tell you whether to rebuild, remove the line, or chase a dependency. Don't dkms autoinstall blind and hope.

When the module itself won't build or insert

Sometimes the module fails because it can't compile against your current kernel. This is common with out-of-tree drivers: graphics drivers, VPN modules, VirtualBox additions, anything built by DKMS.

The usual culprit is a version mismatch. Your running kernel was built with one GCC compiler version, and DKMS is trying to build the module with a different one. The module then refuses to insert with Exec format error or a version compatibility complaint. Check dmesg for a line mentioning version compatibility; that tells you the module and kernel disagree on how they were built.

Two more real causes:

• Missing kernel headers. DKMS can't build against headers that aren't installed. Install linux-headers-$(uname -r) (Debian family) or kernel-devel (Red Hat family) and rebuild.
• Hardware compatibility. A new device may need a module your kernel version simply doesn't ship yet. No amount of rebuilding invents a driver that isn't written. Here a newer kernel is the honest fix, not a workaround.

If you hit a broken module tree during the rebuild, my writeup on the missing kernel modules tree error walks the exact path out.

NixOS and VirtualBox guests change the fix

Two setups need a different approach than "edit the file and reboot." Read the one that matches your box.

NixOS rebuilds the config out from under you

On NixOS the fix is never editing /etc/modules-load.d/ by hand, because Nix rebuilds that file from your configuration on the next switch and throws your edit away. That trips people coming from Ubuntu who expect to nano a file and reboot.

NixOS declares kernel modules in configuration.nix, through boot.kernelModules and boot.initrd.kernelModules. If one of those lists names a module that doesn't exist in the kernel package you pinned, the load fails at boot with the same message. The real problem is a mismatch between a declared module name and the kernel generation you actually booted.

Check two things. First, whether the module belongs to linuxPackages and is built for your chosen kernel; some modules live in linuxPackages.<name> and must be added there, not just named as a string. Second, whether you booted an older generation from the boot menu whose config doesn't match the module set you expect.

Recovery is clean on NixOS. Pick the previous generation at the GRUB menu, boot a known-good system, correct the module declaration, then nixos-rebuild switch. You never lose the working generation, so there is no reason to force a broken one.

VirtualBox guest additions break after a kernel update

A Linux guest under VirtualBox loads Guest Additions modules like vboxguest, vboxsf, and vboxvideo. After the guest kernel updates, those modules were built against the old kernel and no longer insert. The load service then waits on them at boot.

Reproduce it with sudo modprobe vboxguest. If it fails with a version error, the Guest Additions need rebuilding against the new guest kernel. Reinstall or rerun the Guest Additions build, or rebuild via DKMS if it's registered there, then reboot.

If you don't need shared folders or the extra features, the faster fix is to stop force-loading them. Remove the vbox entries from the modules-load config so the boot job isn't waiting on drivers you're not using. Don't mask the whole service to dodge three lines.

Will a system update or LTS kernel actually fix this?

Sometimes, and only when the root cause is genuinely a version mismatch or a driver your current kernel lacks. Updating pulls newer modules and can rebuild DKMS modules against the new kernel, which resolves a real incompatibility. That is a fix.

But an update is not a diagnosis. If your problem is a bad line in /etc/modules-load.d/ naming a module that never existed, updating changes nothing except your patience. I've watched people apt upgrade five times against a typo. Read the log first, then decide whether an update is even relevant.

An LTS (Long Term Support) kernel helps in one case: you're on a bleeding-edge kernel and an out-of-tree module hasn't caught up to its API changes. Dropping to an LTS kernel gives the module a stable target it already supports. That is a deliberate choice based on evidence from dmesg, not a shot in the dark. Switching kernels to "try something" usually just swaps one broken module set for another.

Keeping this from coming back

Prove the root cause is gone, then lock the config so nothing re-adds the bad entry. Here is the routine I run after any fix.

1. Verify with the log, not with vibes. Reboot and run journalctl -b -u systemd-modules-load.service. A clean boot shows no failed load and no timeout. If the service isn't in the critical chain anymore, you're done.

2. Blacklist a module you truly don't want. If a driver keeps trying to load and conflicts, drop a file in /etc/modprobe.d/ with blacklist <module>. That's the correct place to stop a module, not deleting the .ko file, which the next kernel update just restores.

3. Correct the modules-load entries. Every name under /etc/modules-load.d/ should resolve with modinfo. Remove lines for hardware you removed and modules your kernel no longer ships.

4. Keep DKMS honest across kernel updates. After any kernel bump, sudo dkms status should list your out-of-tree modules as installed for the new kernel. If one says added but not built, rebuild it before you reboot into trouble.

For a durable setup on Debian and Ubuntu, my guide to making module loads persistent on Ubuntu covers doing this the right way. And if this hang ever escalates into a full boot stop, the method in diagnosing a kernel panic is the next tool to reach for.

FAQ

How long does the boot job wait before it gives up?
It waits out the service's start timeout, then continues or drops to a shell depending on whether the module was required. That pause is systemd counting down, not a freeze. Watch it once with systemd-analyze blame to see the real number your system used, rather than assuming it's stuck forever.

Can I just mask systemd-modules-load.service to make the message go away?
You can, and you'll regret it the first time a module you actually need doesn't load. Masking hides the failure without fixing the driver, so the missing hardware or filesystem support quietly stays broken. Remove the offending line from the config instead, so only the bad module stops loading.

The module loads fine with modprobe but still fails at boot. Why?
Because at boot the module loads earlier, before the hardware or a dependency is ready, while your manual modprobe runs after everything is up. Check dmesg -T around the boot-time failure for a No such device or missing-firmware line. That timing gap is the whole difference.

Is this the same as a kernel panic?
No. A stalled load service is one unit waiting or failing, and the rest of the system is intact. A panic halts the kernel entirely. If you only see the load-modules message and boot eventually continues or reaches an emergency shell, you are not in a panic and should not treat it like one.

Do I need to compile the kernel from source to fix this?
Almost never. Building a kernel by hand is a last resort for a genuine driver gap that no packaged kernel covers, and it costs real time. Reading the log, rebuilding a DKMS module, or correcting a config line resolves the overwhelming majority of these. Reach for a source build only when you've proven nothing else can supply the module.

Related: Repair Broken Ubuntu Packages Without Guesswork

Related: Fix EasyAntiCheat Kernel Driver Blue Screen Errors