Why is Linux Loading Certain Modules Automatically?

I am doing some embedded Linux development and using Yocto to help me generate rootfs images for my system (this doesn't really matter as my issue is a generic Linux one but thought I would mention it).

I am using a variant of kernel 4.9 which I have modified to include some custom kernel modules/device drivers for my system. To be clear, these custom modules are configured to build as LKMs, not as builtin modules. The Yocto system packages these in my rootfs in /lib/modules/... when I build.

I am finding at boot that some (but not all) of these modules are being automatically loaded when the kernel boots. I do not wish for this to happen at all and wish to manually load them via modprobe instead. I cannot find a reference in my rootfs to how or why these modules are being loaded and they do not have any entries or .conf files present in /etc/modules-load.d.

Note that I am able to use modprobe to remove and load these with no issues but want to ensure that the system doesn't load these automatically.

Any insight to what mechanism might be loading these?

/etc/modprobe.d/blacklist

udev loads the necessary modules. It's probably easier to follow RandonTroll's clue than mess around too much with udev. But you can do it either way.

The /boot/image.initrd has your kernel with modules bundled. This allows you to have your bus, storage, and filesystem modules as "modules" and not built into the kernel. And still be able to boot. There's also /etc/modules that will load modules at boot time. Otherwise /etc/modprobe.d/blacklist.conf is used to prevent modules from auto-magically loading. What is built into the kernel will load when the kernel is booted, because it is "IN" the kernel. Which annoys me with some systems like raspbian which has NFS in the kernel, so you're wasting RAM and CPU cycles for something you might not even use. And various init system processes that will trigger and/or load modules. Like cuse,fuse for mount point fusectl, which you also may never use if you don't access certain filesystems. Generally just the modules for the existing hardware loads. There's a kernel config option $(make localmodconfig) that will create a .config / /boot/CONFIG for just that usage. AKA linux is a lot more annoying than it used to be. But there's a lot more hardware supported too.

not sure if i'm only repeating the previous post, but...

the vanilla kernel is built to support as much hardware as possible.
however, unneeded (as in the hardware is not present) modules are not loaded, or at least not kept loaded.
unneeded (as in the user does not desire) modules can be blacklisted.

if you want more control than that you need to compile your own kernel (or see if someone already did that for your hardware). it's been known to succeed.

Kernel config is a three-hour job now!

Originally Posted by AwesomeMachine Kernel config is a three-hour job now!

I run

make menuconfig

instead or edit .config.

read about depmod(1) and modules.dep

after the kernel builds you can edit modules.dep if you you want (but blacklists are another way)

you have a hole in memory something will read - a real address (perhaps register). if it isn't there: crash.

if B depends on A, you simply have to have A. and the dependency "isn't optional" (for binary blobs runtime: nothing is optional. a PC simply doesn't have the power to check every bit as an option of whether it's there when it's supposed to be)

so the answer is yea you can blacklist but you can't get around the depends.

depends at the "list level" may be general NOT ABSOLUTE. for example - a hole may never be reached if some driver never is put in a particular mode, and the top level depends list is (not big enough) to fully account for all dependant possibilities.

you could just get a hung driver but be careful you could damage your system if you do the opposite of what the developers asked

for a "modules.d" (modules directory, containign files each to be loaded), that's very .de debianish or ubuntu am i right?

that means the init(1) or systemd(1) ran a startup script which invokes a shell script that walks the directory tree calling modprobe on each item in in file. very simple. other systems are far simpler: /etc/modules is a single list and invoked indirectly by /etc/init.d/rcS

a problem has been (of late, in the 20teens), no one learns or cares about standards. "i reject your reality and replace it with my own"

that means you might get your answer today that works: and tomorrow after and automatic update it's the past (broken in ways not worth fixing)

Originally Posted by X-LFS-2010 for a "modules.d" (modules directory, containign files each to be loaded), that's very .de debianish or ubuntu am i right?

Seems close to a standard to me. Although IME, the modules.d is to load "options" for modules "when" they are loaded, and not an automagic load of the modules. At least that's how it used to be when you needed a config there or alsa had to be loaded the hard way. By insmod'ing modules in a specific order. With the proper .conf, it would load the modules WHEN the sound device was "used". Technically "used" at boot time when the mixer levels were restored in most cases.

I run mostly .deb based distros. And I'm not sure if redhat has moved away from conf.modules and other oddities. One of those tldp does not apply unique-nesses that drove me to debian in the first place. All the generic documentation saying modules.conf, and redhat using conf.modules (in a time before modules.d). I started on SuSE which annoyed me a bit too as none of the tldp applied because it was so scripted and expected everything to be done with YaST. Although most of that is getting to be close to 20 years ago at this point.