Stop modprobe from getting confused when you have duplicate module aliases

Technical Briefing | 8/15/2026

You spend half an hour hunting down why your custom network driver isn’t loading on boot, even though you explicitly dropped the conf file into /etc/modprobe.d/. You check the logs, run depmod, and everything looks sane. But the kernel picks a different module every single time because two drivers share the same hardware alias. It is a nightmare when hardware vendors copy-paste device IDs and you are left to clean up the resulting mess.

Why the kernel guesses wrong

The kernel’s module loader uses a database generated by depmod. When a device fires an event, udev triggers modprobe to search for a driver matching the alias. If two modules claim the same ID, the one that appears first in the modules.alias file usually wins the race. Most tutorials ignore that you can actually force the issue with blacklist entries, but that is the blunt instrument approach. A better way is to use softdep to manage dependencies or simply prevent the unwanted module from ever seeing the light of day.

grep -r 'your_device_id' /lib/modules/$(uname -r)/modules.alias
modprobe --show-depends your_driver_name

• Check /lib/modules/$(uname -r)/modules.alias to see the collision
• Use blacklist in a modprobe.d file to stop the unwanted module from loading
• Verify your preferred driver is marked as install instead of just relying on auto-detection

Taking control of the load order

If you find yourself stuck with this, don’t just delete the conflicting driver. Rename the .ko file or use install directives in /etc/modprobe.d/ to ensure your driver loads with the parameters you actually need. If the module is built-in to the kernel, you are stuck with kernel boot parameters, but for anything loaded as a module, you have the upper hand if you know where the loader looks first. Next time your hardware fails to initialize, look at the alias map before you spend more time recompiling the kernel.