modinfo Command in Linux: Complete Guide to Displaying Module Information and Parameters

Abdul Wahab Junaid

3 years ago

modinfo command in Linux and it perimeters

Before you load a kernel module — especially one you’re not already familiar with — it’s worth knowing what it actually does, what parameters it accepts, who wrote it, and what license it’s under. modinfo answers all of that without touching the running kernel at all. It’s one of those commands that’s easy to overlook until the day you need to know exactly what options a driver supports, and grep-ing through kernel source isn’t an option.

What modinfo Actually Is

modinfo extracts and displays the metadata embedded inside a kernel module file (.ko, or compressed variants like .ko.xz/.ko.zst). This metadata is compiled directly into the module by the kernel build system, using macros like MODULE_AUTHOR(), MODULE_DESCRIPTION(), MODULE_LICENSE(), and MODULE_PARM_DESC() in the module’s C source. modinfo is purely read-only and non-invasive — it doesn’t load the module, doesn’t need the module to currently be loaded, and doesn’t require anything beyond read access to the module file itself.

Basic Syntax

modinfo [options] module_name | filename

You can pass either a bare module name (and modinfo searches the standard module directories for the currently running kernel) or a direct path to a .ko file.

A Basic Example

modinfo e1000e

filename:       /lib/modules/6.8.0-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko.zst
version:        3.2.6-k
license:        GPL v2
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     8A3F1C2B9D9E4F5A6B7C8D9
alias:          pci:v00008086d000015E1sv*sd*bc*sc*i*
alias:          pci:v00008086d00001570sv*sd*bc*sc*i*
depends:
retpoline:      Y
intree:         Y
name:           e1000e
vermagic:       6.8.0-generic SMP mod_unload
parm:           debug:Debug level (0=none,...,16=all) (int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           InterruptThrottleRate:...

Each field tells you something specific and useful:

filename — the exact path on disk of the compiled module.
version — the module’s own version string, if it defines one.
license — the declared kernel license (GPL, GPL v2, Dual BSD/GPL, Proprietary, etc.), which also affects what kernel symbols the module is allowed to use.
description — a short human-readable summary.
author — who wrote/maintains it.
alias — the device ID patterns (PCI, USB, etc.) that udev/modprobe use to automatically match hardware to this module.
depends — comma-separated list of other modules this one depends on.
vermagic — the exact kernel version/configuration this module was built against; a mismatch here is the classic cause of “module not found for this kernel” errors.
parm — each loadable parameter the module accepts, with a description and its expected type.

Full Option Reference

-a, --author         print only the 'author' field
-d, --description    print only the 'description' field
-l, --license         print only the 'license' field
-p, --parameters       print only the 'parm' fields (module parameters)
-n, --filename         print only the 'filename' field
-F, --field FIELD      print only the value(s) of the named field
-0, --null              use \0 instead of \n as field separator
-k, --set-version KRNL  provide information about a module for kernel KRNL, not the current one
-b, --basedir DIR       use DIR as filesystem root for /lib/modules
-V, --version           show modinfo version
-h, --help              show help

Getting Just the Parameters

modinfo -p e1000e

debug:Debug level (0=none,...,16=all) (int)
copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
InterruptThrottleRate:Interrupt Throttling Rate (array of int)

This is the single most useful invocation when you’re about to configure a driver via /etc/modprobe.d/ — you find out exactly what options exist and what type they expect (int, uint, bool, charp, array types) without digging through kernel documentation or source.

Getting a Single Field

modinfo -F license e1000e

GPL v2

Handy in scripts where you need to programmatically check, say, whether a module is GPL-licensed before deciding whether it’s safe to load on a system with strict license policies.

Checking a Module for a Different (Not-Currently-Running) Kernel

modinfo -k 6.7.0-generic e1000e

Useful when you’re preparing to boot into a newly installed kernel and want to confirm the module (and its parameters) still exist and match what you expect, before you reboot into it.

Inspecting a Module File Directly (Not Yet Installed)

modinfo ./my_custom_driver.ko

Works even for out-of-tree modules that aren’t in the standard /lib/modules/ tree at all — you can inspect them the moment they’re built, before installing them anywhere.

Real-World Examples

Confirming a module’s dependencies before manually loading with insmod (which doesn’t resolve dependencies itself):

modinfo -F depends nf_conntrack

(An empty result means no dependencies — safe to insmod directly.)

modinfo -F depends vfat

fat

(This tells you to insmod fat.ko first, then vfat.ko — or just use modprobe vfat, which does this automatically.)

Auditing licenses across all currently loaded modules (useful on systems with strict open-source compliance policies):

for mod in $(lsmod | awk 'NR>1{print $1}'); do
    lic=$(modinfo -F license "$mod" 2>/dev/null)
    echo "$mod: $lic"
done

Discovering tunable parameters before writing a /etc/modprobe.d/ config:

modinfo -p nvidia 2>/dev/null | grep -i power

Verifying vermagic matches the running kernel (troubleshooting a load failure):

echo "Running kernel: $(uname -r)"
modinfo -F vermagic ./out_of_tree_driver.ko

If these two don’t match closely, that’s almost certainly why insmod/modprobe is refusing to load the module.

Quick documentation lookup during driver debugging:

modinfo -d -a e1000e

Intel(R) PRO/1000 Network Driver
Intel Corporation, <linux.nics@intel.com>

How modinfo Works Internally

Kernel modules are ELF object files, and the metadata modinfo reads is stored in a dedicated ELF section (.modinfo) within that object file, populated at compile time by the MODULE_*() macros in the driver’s source code. modinfo simply parses this ELF section directly — it doesn’t consult /proc, /sys, or any running-kernel state, and it doesn’t need root privileges for modules that are world-readable (which is the default for standard distro-shipped modules under /lib/modules/). This is exactly why it works identically whether the module is currently loaded, not loaded, or not even installed on the system yet — as long as you have the file.

Troubleshooting

“modinfo: ERROR: Module <name> not found” — either the module name is misspelled, it’s not installed for the currently running kernel, or you need to pass a path directly instead of a bare name. Try find /lib/modules/$(uname -r) -iname "*name*" to locate it.

Output missing expected fields (like parm) — not every module defines every possible field; a module with no configurable parameters simply won’t show any parm: lines, which is normal, not an error.

vermagic looks unfamiliar or doesn’t match uname -r — this is the primary diagnostic signal for “this module won’t load on my current kernel”; it needs to be rebuilt (often automatically handled by DKMS for third-party drivers) against the currently running kernel headers.

Security Considerations

Checking license: before loading unfamiliar or third-party modules is a reasonable first step — modules can be GPL, Proprietary, or a range of other licenses, and this also determines whether the module can use EXPORT_SYMBOL_GPL() kernel functions (a Proprietary module attempting to use GPL-only symbols will fail to load, sometimes with confusing errors).
Since modinfo never loads code, it’s a completely safe first step when investigating an unfamiliar .ko file you’re not yet ready to trust enough to actually insmod/modprobe — read the metadata, check the author and description, before running anything.
On systems doing kernel module signing/verification, modinfo output does not itself confirm a module’s cryptographic signature is valid — that’s a separate check (see modinfo -F signer where available, and kernel lockdown mode documentation) from the descriptive metadata modinfo primarily reports.

Comparison to Related Commands

modprobe — actually loads the module (and its dependencies); modinfo only inspects it.
lsmod — shows what’s currently loaded and its live reference count/dependents; modinfo shows the static metadata baked into the file itself, regardless of whether it’s loaded.
insmod — loads a single module file with no dependency resolution; often used right after checking modinfo -F depends to know what to load first.
depmod — builds the system-wide dependency database; modinfo‘s depends: field reflects the same underlying dependency information for a single module, but read directly from that module’s ELF metadata rather than from the pre-built modules.dep cache.

modinfo‘s output format and options are essentially identical across Debian, Ubuntu, RHEL, CentOS, Fedora, SUSE, and Arch, since it’s part of the same kmod toolkit used everywhere. Field availability can differ slightly module-to-module depending on which MODULE_*() macros the original driver author chose to include.

Summary

modinfo is the safe, read-only way to understand a kernel module before you commit to loading it — what it does, who wrote it, what it depends on, and exactly what parameters it accepts and in what format. Make it a habit to run modinfo -p before writing any /etc/modprobe.d/ configuration, and to check vermagic/depends first whenever a module refuses to load.

References

man modinfo on your local system
kmod project documentation
Linux Kernel Module Programming Guide (kernel.org)
Linux kernel source: include/linux/module.h for the MODULE_*() macro definitions that populate this metadata