depmod Command in Linux: Complete Guide to Building Module Dependencies and Parameters

Behind every clean, dependency-aware modprobe some_module call sits a file that depmod built. Most administrators never run depmod manually — it happens automatically every time you install a kernel package or add third-party modules through a proper package manager — but the day you build or install a module by hand and modprobe mysteriously can’t find it, depmod is exactly the command you need to understand.

What depmod Actually Is

depmod scans the kernel module directory tree for a given kernel version, determines the dependency relationships between all modules (which module requires which other modules to be loaded first, based on unresolved symbol references), and writes that information out to a set of index files. modprobe reads these index files to know exactly what to load, and in what order, whenever you request a single module by name.

Without a current, accurate depmod database, modprobe degrades significantly — it may fail to find modules at all, or fail to resolve dependency chains correctly.

Basic Syntax

depmod [options] [kernel_version]

Run with no arguments, it rebuilds the dependency database for the currently running kernel (uname -r).

A Basic Example

sudo depmod

No output on success — depmod is silent unless there’s a problem or you ask for verbosity. It regenerates the index files under:

/lib/modules/$(uname -r)/

What Files depmod Actually Produces

modules.dep          # the core dependency map
modules.dep.bin       # binary-indexed version for fast lookup
modules.alias         # hardware ID -> module name mappings
modules.alias.bin
modules.symbols        # which module exports which symbol
modules.symbols.bin
modules.builtin.bin    # index of modules built directly into the kernel
modules.softdep         # soft dependency hints ("load X before/after Y")
modules.order

modules.dep is the one worth actually looking at — it’s human-readable:

grep vfat /lib/modules/$(uname -r)/modules.dep

kernel/fs/fat/vfat.ko.zst: kernel/fs/fat/fat.ko.zst

This line says: to load vfat.ko.zst, first load fat.ko.zst. This is precisely the information modprobe vfat consults to automatically load fat first.

Full Option Reference

-a, --all              probe all kernels, not just the current one
-A, --quick            only rebuild if a module is newer than the existing modules.dep
-b, --basedir DIR       use DIR as the filesystem root instead of /
-C, --config FILE       use FILE instead of the default depmod.conf search path
-e, --errsyms            report symbols a module needs that no other module supplies
-E, --symvers FILE       use a Module.symvers file to cross-check symbol versions
-F, --filesyms FILE      use a System.map-style file for symbol resolution
-n, --show                write the dependency file to stdout instead of disk (dry run)
-P, --symbol-prefix P    supply a symbol prefix used on some architectures
-w, --warn                warn about duplicate module names/aliases
-v, --verbose             print each module processed
-u                         (deprecated no-op on modern kmod, kept for compatibility)
-q, --quiet               suppress warnings
-V, --version             print version
-h, --help                print help

Building for a Kernel Version That Isn’t Currently Running

This is the single most important real-world use case — you’ve just installed a new kernel package, but haven’t rebooted into it yet:

sudo depmod 6.9.0-generic

Without this, if you reboot into that kernel and something (an initramfs hook, a package post-install script) doesn’t run depmod for you automatically, modprobe will fail to find modules on the new kernel even though the module files themselves are physically present on disk.

In practice, on virtually every modern distribution, this happens automatically as part of the kernel package’s post-installation scripts — but it’s essential to understand when you’re doing anything unusual, like building an out-of-tree module manually or working with custom kernel builds.

Rebuilding for All Installed Kernels

sudo depmod -a

Useful after installing a third-party out-of-tree module (common with certain proprietary drivers or DKMS-managed modules) that needs its dependency information registered across every kernel version currently installed on the system, not just the running one.

Dry Run

depmod -n | grep mymodule

Prints what would be written, without touching any files — a safe way to verify the dependency resolution looks correct before committing to it.

Verbose Mode

sudo depmod -v 2>&1 | head -20

kernel/fs/fat/fat.ko.zst
kernel/fs/fat/vfat.ko.zst needs "fat":

Checking for Unresolved Symbols

sudo depmod -e

This flags any module that references a kernel symbol that isn’t provided by the running kernel or any other currently-scanned module — genuinely useful right after building and installing a custom or third-party module, since it surfaces exactly the kind of mismatch that later shows up as a cryptic “Unknown symbol” error at modprobe/insmod time.

When You Actually Need to Run depmod Manually

In day-to-day administration, you rarely need to invoke depmod by hand, because:

• Installing a kernel package via apt/dnf/zypper triggers it automatically as part of the package’s post-install hooks.
• DKMS (Dynamic Kernel Module Support) — used by many third-party drivers to rebuild themselves against new kernels — runs depmod automatically after building.

You do need to run it manually when:

• You’ve manually copied a .ko file into the module tree (e.g., /lib/modules/$(uname -r)/extra/) without going through a package manager or DKMS.
• You’ve cross-compiled or manually installed modules for a kernel version other than the currently running one.
• modprobe reports “module not found” for a module you can clearly see exists on disk with find.
• You’re debugging dependency resolution issues and need a dry-run (-n) look at what modprobe would actually do.

Real-World System Administration Examples

Installing a manually-built out-of-tree module:

sudo mkdir -p /lib/modules/$(uname -r)/extra
sudo cp mydriver.ko /lib/modules/$(uname -r)/extra/
sudo depmod -a
sudo modprobe mydriver

Skipping depmod -a here is the single most common reason this exact workflow fails with “module not found” even though the file is clearly present.

Post-kernel-install verification script:

#!/bin/bash
NEW_KERNEL="6.9.0-generic"
sudo depmod "$NEW_KERNEL"
if depmod -n "$NEW_KERNEL" > /tmp/depmod_check.txt 2>&1; then
    echo "depmod succeeded for $NEW_KERNEL"
else
    echo "depmod FAILED for $NEW_KERNEL — check /tmp/depmod_check.txt"
    exit 1
fi

Finding modules with unresolved symbols after a custom kernel build:

sudo depmod -a -e 2>&1 | tee /var/log/depmod_errors.log

How depmod Works Internally

depmod walks the entire module tree for the target kernel version (/lib/modules/<version>/), and for every .ko (or compressed .ko.xz/.ko.zst) file it finds, it reads the module’s ELF symbol table to see:

1. What symbols the module exports (available for other modules to use).
2. What symbols the module requires but doesn’t define itself (unresolved references).

It then cross-references every module’s “requires” list against every other module’s “exports” list, building the full dependency graph, and serializes the result into modules.dep (plus the .bin indexed versions for fast lookup by modprobe, since parsing a large plain-text file on every single modprobe call would be needlessly slow on systems with hundreds of modules).

Troubleshooting

“modprobe: FATAL: Module X not found” despite the file clearly existing in /lib/modules/$(uname -r)/ — almost always means depmod hasn’t been run since that module was added; fix with sudo depmod -a.

Dependencies load in the wrong order / fail with unresolved symbol errors — the modules.dep file may be stale relative to the actual module files (e.g., after manually replacing a .ko file with a different version); rebuild with sudo depmod -a.

Duplicate module name warnings — run depmod -w to surface these explicitly; typically caused by having both a distro-shipped and a manually-installed/DKMS-built copy of the same module present simultaneously, which can lead to modprobe loading the wrong one.

Changes to /etc/depmod.d/ config not taking effect — confirm you re-ran depmod after editing configuration (search path overrides, symbol overrides); config files don’t take effect until the dependency database is rebuilt.

Performance Considerations

depmod -a scanning every installed kernel’s full module tree can take a few seconds on systems with many kernels installed and many out-of-tree modules — this is normal and not something to optimize away in most cases, since it only runs during kernel/module installation events, not on every boot or every modprobe call (that’s the whole point of pre-building the index).

Comparison to Related Commands

• modprobe — the consumer of depmod‘s output; loads modules using the dependency graph depmod builds.
• modinfo — shows a single module’s own declared depends: field (read directly from that module’s metadata), which is closely related conceptually but is not the same as the full cross-referenced dependency graph depmod computes across the entire module tree.
• insmod/rmmod — operate with zero awareness of depmod‘s dependency database at all; this is precisely why they require you to resolve and load/unload dependencies manually, in contrast to modprobe.
• DKMS — a higher-level system for automatically rebuilding out-of-tree modules against new kernels, which itself invokes depmod as part of its own workflow.

depmod‘s command-line interface and file formats are standardized across Debian, Ubuntu, RHEL, CentOS, Fedora, SUSE, and Arch, since they all use the same kmod implementation. The main difference across distros is simply when it gets invoked automatically (kernel package post-install hooks vary slightly in exact scripting, though the end effect is the same).

Summary

depmod is infrastructure you rarely touch directly but constantly depend on — it’s the reason modprobe some_module “just works” without you having to manually chase down and load a chain of prerequisite modules yourself. The moment you step outside the paved path of package-manager-installed kernels and modules — manually building a driver, working with DKMS, testing on a not-yet-booted kernel — knowing when and how to run depmod -a becomes essential, not optional.

References

• man depmod, man depmod.d on your local system
• kmod project documentation
• Linux Kernel Module Programming Guide (kernel.org)
• DKMS project documentation, for automated out-of-tree module rebuilding workflows