VMware ESXi and vSphere Cluster Management

Remove Loaded Kernel Modules in Linux with rmmod

Learn how to inspect and unload Linux kernel modules with lsmod, rmmod, and modprobe -r, handle dependencies safely, and understand the risks of forced removal.

A kernel module is a loadable component that extends the capabilities of the running Linux kernel. Modules commonly provide device drivers, filesystem support, networking features, and other optional kernel capabilities.

Linux can keep module code available on disk without loading it into memory. A compiled module usually has a .ko filename extension. An installed module is only a file available to the system; a loaded module is currently active in the running kernel. This lesson covers removing the latter.

Why remove a loaded kernel module?

  • Free memory used by a module that is no longer needed.
  • Temporarily disable a driver or optional kernel feature.
  • Prepare to load a replacement or updated module during troubleshooting.

Unloading a module can interrupt hardware access or services that depend on it. Before removal, stop relevant services, unmount filesystems, disconnect affected devices, or otherwise end activity that uses the driver or feature.

Inspect loaded modules before removal

Use lsmod to list modules currently loaded into the running kernel:

lsmod

Typical output includes these useful fields:

  • Module: the loaded module name.
  • Size: the amount of kernel memory associated with the module.
  • Used by: the use count followed by modules that currently depend on it.

The use count is an indicator that a module is referenced by other modules or active kernel functionality. A nonzero count commonly prevents ordinary removal, although the precise cause should be investigated rather than guessed.

To search for a particular module:

lsmod | grep -i <module>

Use modinfo when you need metadata, aliases, parameters, or dependency-related information:

modinfo <module>

Use the module identifier, not the path to its compiled file. For example, pass example_driver, not /lib/modules/.../example_driver.ko.

Remove a module with rmmod

rmmod is the direct, low-level utility for requesting removal of a loaded kernel module. The basic form is:

sudo rmmod <module>

Module names are commonly written with underscores, such as example_driver. Linux module tooling may accept a hyphenated equivalent such as example-driver in some contexts, but use the name shown by lsmod when possible.

Example: remove a simple unused module

  1. Confirm that the module is loaded:
lsmod | grep -i example_driver
  1. Request normal removal:
sudo rmmod example_driver
  1. Verify that it is no longer listed:
lsmod | grep -i example_driver

If the final command produces no matching line, the module is not currently listed as loaded. A successful removal changes the running system only; it does not delete the module file from disk.

Dependencies and modules in use

A module dependency exists when one module needs another module to remain loaded. The dependent module is sometimes called the consumer, while the module it needs is the provider. The provider ordinarily cannot be unloaded until its consumers have been removed.

A module can also be busy because a device, service, mounted filesystem, or network function is actively using it. In these cases, rmmod reports an error describing an in-use or dependency problem. The correct removal order is from consumers to providers.

For example, if module consumer_mod requires provider_mod, remove them in this order:

sudo rmmod consumer_mod
sudo rmmod provider_mod

Inspect lsmod output to identify likely consumers. Use modinfo for additional metadata and dependency details:

lsmod
modinfo provider_mod

modprobe is a module-management utility that resolves dependencies when loading or removing modules. Its removal form can remove a target and removable dependent modules:

sudo modprobe -r <module>

This is often more convenient than manually finding and removing every dependent module, but it still cannot safely remove modules that remain actively used.

Example: removal blocked by a dependent module

  1. Attempt normal removal and read the error:
sudo rmmod provider_mod
  1. Inspect the loaded-module list and metadata:
lsmod
modinfo provider_mod
  1. Stop the service or workload using the feature, then remove the consumer:
sudo rmmod consumer_mod
  1. Retry the provider, or use dependency-aware removal when appropriate:
sudo rmmod provider_mod
# Alternative:
sudo modprobe -r provider_mod

Controlled replacement during troubleshooting

Unloading can be useful when replacing a driver or testing a changed module. Use a controlled sequence:

  1. Stop services and applications using the affected device or feature.
  2. Unmount relevant filesystems or disconnect affected hardware when applicable.
  3. Inspect dependencies with lsmod and modinfo.
  4. Remove dependent modules first, or use sudo modprobe -r <module>.
  5. Load the desired module with modprobe if needed.
  6. Validate device and service operation, then check kernel messages if anything fails.
sudo modprobe <module>
lsmod | grep -i <module>

Force removal with rmmod -f

The -f option requests a forced unload:

sudo rmmod -f <module>

Forced removal is available only when the running kernel was built with CONFIG_MODULE_FORCE_UNLOAD enabled. Support is therefore kernel-build dependent; the option is not guaranteed to work on every system.

If rmmod -f is unavailable or rejected, do not assume that changing the kernel configuration is appropriate. Stop the workload, remove dependent modules, and retry ordinary removal. Forced unloading is best reserved for exceptional diagnostic or recovery situations where its risks are understood.

Command reference

Command — Purpose — When to use — Key caution

lsmod — Lists modules currently loaded in the running kernel — Before and after removal — It shows runtime state, not every module installed on disk.

modinfo <module> — Displays metadata, aliases, parameters, and dependency-related information — When the module identity or dependencies need inspection — The module does not have to be loaded for all metadata to be available.

sudo rmmod <module> — Requests direct removal of one loaded module — When dependencies and active use are clear — Use a module name, not a .ko filesystem path.

sudo modprobe -r <module> — Removes a module with dependency-aware handling — When removable dependent modules should be handled automatically — Active users can still prevent removal.

sudo rmmod -f <module> — Requests forced removal — Exceptional diagnostic or recovery cases only — Requires CONFIG_MODULE_FORCE_UNLOAD and may crash or destabilize the system.

Troubleshooting removal failures

Outcome or message type — Likely cause — Recommended response

Successful removal — The module was loaded and not needed by active users — Run lsmod again and confirm it is absent.

Module is not currently loaded — It is already absent, or the supplied name does not match — Search with lsmod, verify the identifier with modinfo, and do not supply a .ko path to rmmod.

Module is in use — A device, service, filesystem, or network function is active — Stop the workload, disconnect or unmount affected resources, and retry normal removal.

Dependent module remains loaded — Another loaded module requires the target — Identify the consumer with lsmod or modinfo, remove consumers first, or try modprobe -r.

Permission denied — The command lacks administrative privileges — Use sudo or an authorized root shell.

Forced unload unsupported — The kernel was not built with CONFIG_MODULE_FORCE_UNLOAD, or the current state does not permit it — Resolve dependencies and active use instead of relying on force.

Check kernel messages

After a failure or unexpected device behavior, inspect kernel messages with the tools available on your system, such as dmesg or journalctl. Messages can reveal driver errors, failed cleanup, or a resource that is still active. Verify the final state with:

lsmod

Runtime removal and persistence

rmmod affects only the currently running system. The module may load again after reboot, hardware detection, service startup, or an explicit modprobe request.

If the actual goal is to prevent automatic loading in future sessions, runtime removal is not enough. A blacklist is configuration intended to prevent automatic loading of a module. Boot-time module configuration and blacklisting are separate administration tasks and should be used only after confirming that the driver is not required for boot, storage, networking, or recovery.

Exam-relevant notes

  • rmmod directly requests removal; lsmod lists modules currently loaded; modprobe manages loading and dependency-aware removal.
  • Use a module name such as example_driver, not the path to an .ko file.
  • Remove dependent consumer modules before their provider module.
  • A nonzero use count or an active device can block ordinary unloading.
  • rmmod -f requires CONFIG_MODULE_FORCE_UNLOAD and is dangerous, not a standard fix.
  • Removing a module at runtime does not blacklist it or delete it from disk.

For this topic, return to the Linux kernel module removal guide when reviewing the normal workflow and safety checks.