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 —
insmodwill 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
insmodperforms 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 amodprobe-level concept, not something the kernel orinsmoditself 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
-fto 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 toinsmod, with the same “no dependency awareness” characteristic.modinfo— inspect a module’s metadata, dependencies, and parameters before loading it withinsmod, so you know exactly what you’re about to insert and in what order dependencies need to go.depmod— builds the dependency database thatmodprobeuses but thatinsmoddeliberately 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 insmodon your local systemkmodproject documentation- Linux Kernel Module Programming Guide (kernel.org)
- Kernel documentation on module signing and Secure Boot lockdown (
Documentation/admin-guide/module-signing.rstin the kernel source tree)