Remove Module Linux

[Niobe Hennigan]

Iwould like to ask you how can I delete some kernel module completely? I mean really delete, not unload or prevent to load. I tried to use rmmod, but it just unloaded module, same as modprobe -r. So I got list of all modules using modprobe -n -v and deleted them manually.

Linux loadable modules are ko files located in /lib/modules/$(uname -r)/, sorted into sub-folders. A few files in this folder helps handling them all, especially modules.dep[.bin] and modules.order[.bin]. modprobe read those files to get full path of a module and its dependencies.

On most Linux distributions, module files are installed by packages of your package manager. A core set of them is installed by a quite generic package named kernel-modules for example, and on some distributions extra less-used modules can be installed by specific packages (modules are split into several packages). You can find which packages provides unwanted modules and uninstall them.

You may be tempted to edit text files to remove references of unwanted modules, but editing binary files counterparts is likely tedious and those files will be recovered every time their package gets updated.

Small embedded systems can still rely on loadable modules, but may not provide any package managers.You may need to rebuild your embedded system entirely to alter it since some embedded systems use read-only root file systems.

You can save a bit of disk space by building your own kernel that has the module configured out. The kernel will be a very tiny bit faster using the relevant functionality if you build a kernel that includes (not as modules, builtin) whatever you need. But that is a huge hit in flexibility and hassle.

If a kernel module is not loaded, it's the same as if it doesn't exist, unless it was built into the kernel (I'll explain that below), the only exception is you typically can later reload it with an insmod command.

The reason why you get the path in the error message with modprobe is because modprobe is hardcoded to check standard locations for modules (reference). There's no configuration file or anything telling modprobe to do that. (If your module is not in the standard paths and you want to insert it you can always use insmod).

Modules are loaded by some mechanism outside of the kernel after the kernel starts. systemd can load modules, so can udev. You have to find out what mechanism your system uses and blacklist a module from that.

The proc virtual filesystem is not mounted. Things like chroot, SELinux, and kernel capabilities can prevent you from accessing or mounting /proc even as root. Check if you can ls /proc and get something like that looks like a list of directories for each PID on your system. If you are running this in a chroot you have to bind mount /proc into your chroot.

It's possible to build a module into a kernel. This makes it part of the kernel. It's no longer a module at that point so rmmod and other things won't work. I am not sure what will happen if you try to insmod a module that is part of the kernel (it will probably give you a cryptic "file in use" error referring to kernel resources already in use).

I'm writing a loadable kernel module and trying to test it. After inserting it I was trying to remove it using rmmod xxx command, but I get an error saying module xxx is in use and the module gets stuck and I can't remove it. Any idea how to remove the module without rebooting the entire machine ? (linux Kernel v. 3.5.0)

As I said, the kernel usually panics so you should check out dmesg after inserting it or running you application to exercise it. I'm not certain but it might be possible that if the driver doesn't release a mutex this behavior will happen as well.

in most linux distros it is possible to generate /etc/modprobe.d/blacklist.conf which prevents listed kernel modules from being loaded at boot time and thus not having to resort to the drastic measure of removing the module entirely.

Because often people ask about a specific "how" because they believe this "how" to be necessary to solve their real problem. Often enough, the real problem has solutions that do not require to solve the specific "how". Been there, witnessed that from both sides. Also on the internet nobody needs to answer anything so a person asking questions should be friendly towards all responders, even if unhelpful, they are spending their time on your problem, at least acknowledge that. (That does not mean that you need to agree, but IMHO calls to "stay on topic" are not merited, as you can simply ignore answers you deem unhelpful; if an answer is rude, that is a different issue meriting calling it out)

There is no mentioning of a "problem" and I do not comprehend why this lingual characteristic is being introduced/utilized/argued by either of you? It is a straightforward question which has been exhaustively responded to - making it clear what can and what cannot be done.

Not sure what you are getting exited about and unnecessary heating the thread with such statements? Your telling of what one should do or not could be easily mistaken as patronizing. And I am afraid that is not the first time such mannerism is on display.

-f, --force This option can be extremely dangerous: it has no effect unless CONFIG_MODULE_FORCE_UNLOAD was set when the kernel was compiled. With this option, you can remove modules which are being used, or which are not designed to be removed, or have been marked as unsafe (see lsmod(8)).

Yes, this is part of the issue, people in this forum are quite happy to help solve problems, so if you have a problem come forward. If however you have no acute problem, why waste everybody's time?

Most folks here know, that OpenWrt being a linux distribution tailored to low-end devices does not offer everything big Linux distributions offer, so enumerating all differences seems moot unless such a difference causes real problems ;), but then it helps if the problem is stated along with the difference that makes solutions for "normal" linux distributions inapplicable for OpenWrt.

The why is missing, someone less conscious of the dangers of removing a piece of kernel code where other parts of the same kernel might still hold references to than you, might get wrong ideas about when calling rmmod --force my_module is reasonable. (I admit that modprobe -r seems less dangerous in that it tries to also remove the reference holding modules, but that is subtle).

Look, I am not the forum admin, just a user voicing my own opinion, so I try not to talk about can and shall, but rather could and should. IMHO asking a specific question is fine, but even better if accompanied by a description of why the question is relevant. If you have no problem, maybe do not ask a question in the first place?

Sure, that certainly helps, (except all answers are comments even the off-topic ones ). But this is an open forum, as long as the tone stays friendly you can post almost every question, it is just that people will be better to help if they understand the scope of the question better.

Note that I've only tested this when already running the latest Linux kernel installed on my distribution. Your distribution might come with packages that depend on a meta-package, such as linux-generic-hwe-20.04 for Ubuntu 20.04 LTS-based distributions, and I haven't tested this script when running an older Linux after installing a newer one.

The second command to look at is dpkg-query, which lets us query installed packages in different ways. You can use --list for a pretty, interactive display, but I chose to use --show to make scripting simpler.

A determined reader could probably figure out how to use the --showformat option to skip this step, but I preferred a more familiar approach - the cut command. The cut command simply takes standard input, an optional delimiter provided with -d (a tabulator character by default), and a field argument provided with -f. In this case, it takes the output of our dpkg-query command and returns the first column:

We pipe the output of that into the grep command, which lets us select lines that match a certain pattern - or, in this case, lines that don't match a certain pattern, using the -v--invert-match option. The "$(uname -r)" returns a line like 5.15.0-48-generic, which is then used as the pattern to grep. This is how we select all linux-modules packages which are not currently running.

... but in case those are not familiar to you, man sudo allows you to run a command as root, the system administrator (or theoretically another user), which is necessary to use man apt, which manages packages and dependencies on Debian (hence Ubuntu)-based distributions.

will show the packages that are not currently provided by any sources.list (for this Ubuntu version). It includes e.g. manually installed packages from previous Ubuntu versions, if you have been doing upgrades. The issue is, that there are also packages that I wanted keep such as slack, draw.io etc., so you need to manually inspect the packages you don't need anymore.

Theoretically you could delete modules that's not needed on the machine you're on, but if you do a wrong step somewhere, you risk the machine not booting any more. And you'd have to repeat it for every kernel update.

The Linux kernel has a modular design. Functionality is extendible with modules or drivers. Use the modprobe command to add or remove modules on Linux. The command works intelligently and adds any dependent modules automatically.

To keep all this as tidy as possible, I'm posting an update to this other post - =4274 - as a Part II.

In any case, if the admins think it is not proper practise, please advise or edit as needed.

I was not able to find a way to either query or disable any of the e1000e module's EEE settings under Devuan Beowulf.

It occurred to me that it could all be a question of kernel version* or the driver version** or maybe a combination of both.

What I was certain of is that disabling the settings was not an ethtool 4.19 problem.

The maintainer cleared that up: it is up to the e1000e driver module to support access to the settings. ie: query/modify them

I was also certain that the hardware supported EEE, the tty1 output at shutdown was clear enough.

3a8082e126