insmod Command in Linux: Complete Guide to Inserting Kernel Modules and Parameters

insmod is the bare-metal way to get a compiled kernel module into a running kernel. No dependency resolution, no configuration file lookups, no aliases — just “take this exact file, and load it, right now.” That rawness makes it a slightly awkward tool for everyday use, but it makes it invaluable when you’re actively developing or testing a module, because you get to control precisely what’s happening with nothing hidden behind convenience layers.

What insmod Actually Is

insmod inserts a single kernel module, given as a file path, directly into the running kernel. It’s the most low-level of the standard module-management commands — unlike modprobe, it does not consult /etc/modprobe.d/ configuration, does not search standard module directories automatically, and does not resolve or auto-load dependencies. You give it an exact .ko file, and it either loads successfully or reports exactly why it didn’t.

Basic Syntax

insmod filename [module_parameters...]

Note the key difference from modprobe: you pass a file path, not a bare module name, and if that module depends on other modules, you must load those yourself, first, in the correct order.

A Basic Example

sudo insmod /lib/modules/$(uname -r)/kernel/fs/fat/fat.ko.zst
sudo insmod /lib/modules/$(uname -r)/kernel/fs/fat/vfat.ko.zst

Notice fat had to be loaded before vfat manually — insmod has no idea that vfat depends on fat unless you tell it by loading things in the right order yourself. Compare this to the single, dependency-aware call:

sudo modprobe vfat

which resolves and loads the exact same chain automatically.

Verify success either way:

lsmod | grep -E "vfat|fat"

vfat        24576  0
fat         98304  1 vfat

Options

insmod has an intentionally minimal option set compared to modprobe:

-f, --force        force load even with version mismatches (very risky)
-s, --syslog        log messages to syslog instead of stderr
-v, --verbose       print detailed information about what's happening
-h, --help          display help
-V, --version       print version

Verbose Loading

sudo insmod -v ./mymodule.ko

insmod ./mymodule.ko

Combined with checking dmesg immediately afterward, this is the standard workflow when actively developing and testing a new driver.

Passing Module Parameters

Any arguments after the filename are passed directly to the module as parameters, in key=value form:

sudo insmod ./mydriver.ko debug=1 buffer_size=4096

You can discover what parameters a given module accepts, and their expected types, using modinfo -p:

modinfo -p ./mydriver.ko

debug:Enable debug logging (int)
buffer_size:Ring buffer size in bytes (int)

Force Loading (High Risk)

sudo insmod -f ./mydriver.ko

This bypasses the kernel’s version-magic (“vermagic”) compatibility check, which normally prevents loading a module compiled against a different kernel version/configuration than the one currently running. Forcing an incompatible module to load is a very real path to kernel instability, memory corruption, or an outright crash, because the module’s assumptions about kernel internal data structures may simply no longer match reality. This flag exists for specific development and recovery scenarios — not something to reach for to silence a legitimate compatibility warning in production.

insmod vs modprobe: The Core Distinction

This is worth spelling out explicitly, because it’s the single most common point of confusion for people newer to Linux module management:

	insmod	modprobe
Input	Exact file path	Bare module name
Dependency resolution	None — manual, in order	Automatic, via depmod‘s database
Searches standard module directories	No	Yes
Reads /etc/modprobe.d/ config (blacklists, default params)	No	Yes
Resolves hardware aliases	No	Yes
Typical use case	Development, testing, one-off manual loads of a specific build	Everyday system administration, boot-time loading, hardware auto-detection

In practice, day-to-day system administration almost always uses modprobe. insmod earns its keep specifically when you’re testing a module you just compiled yourself and want precise, unmediated control — for example, confirming a freshly built .ko loads correctly before it’s even been copied into the standard module tree or registered with depmod.

Real-World Use Cases

Testing a freshly compiled out-of-tree module during development, before installing it “properly”:

make
sudo insmod ./mydriver.ko
dmesg | tail -20
sudo rmmod mydriver

This tight loop — build, insmod, check dmesg, rmmod, repeat — is a completely standard kernel/driver development workflow, and it’s exactly the scenario insmod is built for: you want to load this specific file, right now, with zero indirection.

Manually loading a module chain to understand dependency order (educational/debugging use):

sudo insmod /lib/modules/$(uname -r)/kernel/fs/fat/fat.ko.zst
sudo insmod /lib/modules/$(uname -r)/kernel/fs/fat/vfat.ko.zst

Doing this by hand once is a genuinely good way to internalize what modprobe is actually automating for you.

Loading a module with a custom debug parameter for a single test run:

sudo insmod ./network_driver.ko debug=3
dmesg | grep -i debug
sudo rmmod network_driver

Verifying a module built for the wrong kernel version fails safely (rather than being forced):

sudo insmod ./old_build.ko

insmod: ERROR: could not insert module ./old_build.ko: Invalid module format

dmesg | tail -3

old_build: version magic '6.7.0-generic SMP mod_unload' should be '6.8.0-generic SMP mod_unload'

The correct fix here is to rebuild the module against the currently running kernel headers (or via DKMS), not to add -f.

Troubleshooting

“insmod: ERROR: could not insert module X: Invalid module format” — a vermagic mismatch; the module was built for a different kernel version. Rebuild it against the current kernel, don’t force-load it.

“insmod: ERROR: could not insert module X: Unknown symbol in module” — the module references a kernel symbol that either doesn’t exist in the running kernel, or belongs to a dependency you haven’t loaded yet. Check with grep -w symbol_name /proc/kallsyms and load any missing dependency modules first (or just use modprobe, which handles this automatically via its dependency database).

“insmod: ERROR: could not insert module X: Operation not permitted” — usually means Secure Boot / kernel lockdown mode is active and the module isn’t properly signed; check mokutil --sb-state and your kernel’s lockdown configuration.

“insmod: ERROR: could not insert module X: File exists” — the module (or one providing the same functionality) is already loaded; check with lsmod before re-attempting.

Security Considerations

• On Secure Boot-enabled systems, the kernel typically enforces module signature verification — insmod will refuse to load unsigned or improperly-signed modules unless you’ve explicitly enrolled your own signing key via MOK (Machine Owner Key) enrollment, or lockdown mode is set to a permissive level. This is a deliberate, important security boundary, not a bug to work around with -f.
• Because insmod performs no dependency or configuration checking at all, it will happily load a module that an administrator has explicitly blacklisted via /etc/modprobe.d/ (since blacklists are a modprobe-level concept, not something the kernel or insmod itself enforces) — this is a real, sometimes-overlooked gap worth knowing about if you’re auditing what can and can’t be loaded on a locked-down system.
• Avoid routinely using -f to bypass vermagic checks; a module compiled against a mismatched kernel version can reference incompatible internal data structures, and there is no reliable way to predict whether that will merely fail loudly or actively corrupt kernel memory.

Comparison to Related Commands

• modprobe — the dependency-aware, configuration-respecting, everyday tool; use this for anything beyond active module development/testing.
• rmmod — the direct removal counterpart to insmod, with the same “no dependency awareness” characteristic.
• modinfo — inspect a module’s metadata, dependencies, and parameters before loading it with insmod, so you know exactly what you’re about to insert and in what order dependencies need to go.
• depmod — builds the dependency database that modprobe uses but that insmod deliberately ignores entirely.

insmod‘s minimal, low-level behavior is consistent across Debian, Ubuntu, RHEL, CentOS, Fedora, SUSE, and Arch, since it’s part of the same kmod package everywhere. The main practical variance you’ll encounter across distros is around Secure Boot/module-signing enforcement defaults, which affect whether insmod will accept a given module at all, independent of the command’s own behavior.

Summary

insmod is the raw, unmediated way to put a specific compiled kernel module file into the running kernel — no dependency chasing, no configuration lookups, no hardware alias matching, just “load exactly this file.” That makes it the wrong everyday tool for general system administration (where modprobe is almost always the better choice) but exactly the right tool when you’re actively building, testing, and iterating on a kernel module yourself and want complete, transparent control over what gets loaded and when.

References

• man insmod on your local system
• kmod project documentation
• Linux Kernel Module Programming Guide (kernel.org)
• Kernel documentation on module signing and Secure Boot lockdown (Documentation/admin-guide/module-signing.rst in the kernel source tree)