Those kernel module parameters? They’re often silently doing their own thing.

Technical Briefing | 10/23/2026

Most folks just `modprobe` a module, maybe pass a quick parameter, and figure they’re done. Or they install a package, and it brings in a module, and that’s that. But sometimes, system behavior changes subtly, or not so subtly, after a reboot, and you’re left scratching your head. I’ve seen things like network performance tanking or hardware accelerators just not kicking in, all because of an undocumented module parameter that didn’t stick or got overridden. It’s a dark corner of Linux operations that doesn’t get enough light.

What the kernel’s actually doing with your module’s knobs

When you load a kernel module, it’s not just a binary blob. Many modules expose configurable options, often called parameters, that modify their behavior at runtime. You can specify these when you load the module with `modprobe`, or even later through `sysfs` for some dynamic settings. But the `modprobe` parameters are often where the silent killers live. These parameters are usually documented, if you know where to look, but they’re rarely advertised in big, flashing letters.

modinfo nf_conntrack | grep parm
cat /sys/module/nf_conntrack/parameters/hashsize
# The above shows its current runtime value. To override at load time:
# options nf_conntrack hashsize=131072
# Add that line to a file like /etc/modprobe.d/99-custom-nf_conntrack.conf

Making your module options stick (and where it goes wrong)

If you just `modprobe some_module param=value`, that change is ephemeral. It’s gone after a reboot. To make it persistent, you need to tell the kernel to load it with those specific parameters every time. The canonical way is through `modprobe.d` configuration files, usually located in `/etc/modprobe.d/`. You drop a file in there with `options module_name parameter=value` lines. And this is where the fun starts.

• Typo in the module name or parameter: The kernel just ignores it. No error, just silent failure.
• Conflicting files: Multiple `.conf` files in `/etc/modprobe.d/` can specify the same option. The last one parsed wins, but determining “last” isn’t always obvious without careful inspection or `modprobe –showconfig`.
• Initramfs wasn’t updated: If a module is part of your initial ramdisk, modifying its options in `modprobe.d` means you need to rebuild the `initramfs` (e.g., `update-initramfs -u` on Debian/Ubuntu, `dracut -f` on RHEL/CentOS). Most tutorials skip this part, and it’s bitten me hard in production with things like storage controllers or early network config.
• Module loaded before `modprobe.d` is processed: This is rare, but if a module is hard-compiled into the kernel or loaded very early in the boot process before userland `modprobe` gets a say, your config files won’t apply.

I’ve seen `nf_conntrack` hash size issues where a misconfigured parameter led to connection tracking table overflows under load, silently dropping new connections. And it looked like a networking issue. Hours were spent debugging firewalls and NICs before someone finally dug into `modinfo` output and then the `/etc/modprobe.d/` directory, only to find a typo in a years-old configuration file. This kind of stuff isn’t flashy, but it’s exactly the kind of silent killer that wastes days.

So, next time you’re troubleshooting some strange low-level behavior, and you suspect a kernel module might be involved, don’t just check its runtime parameters via `sysfs`. Dig into `modinfo` to see what options it *can* take, and then scrutinize `/etc/modprobe.d/` for any lurking `.conf` files. And for modules bundled into your `initramfs`, make sure that `initramfs` got rebuilt after your changes. It’s tedious, but it’ll save your sanity.