changes to modprobe.conf

[joe_91]

In RHEL 5 (or 4) whenever i change the modprobe.conf should i reboot for the changes to take effect or is there a way to re-read the modprobe.conf file?
(what about depmod??)

Thanks

Joe.

[Matti_Kurkela]

If you run "depmod" after modifying modprobe.conf, the new settings will be used the next time the "modprobe" command is run (either automatically or manually). No reboot is required.

But if you change something that is normally referenced at boot-time only, you will have to do something further (typically unload & reload the module whose settings you modified) to make those settings effective immediately. What you need to do depends on what you're changing: if you're adding or changing options for a module, you'll have to unload & reload that module. If you're changing module aliases to switch one module for another, you must unload both modules first.

Remember that modules typically won't unload if something is using them.

MK

[joe_91]

Matti

In essense are you saying it is better to reboot (as most of the modules would be used anyway). Could you give me an example where you make changes to modprobe.conf and make it work w/o reboot as opposed to a case where it is better to reboot?

Thanks much for your help.

Best Regards

Joe.

[skt_skt]

What change were u making ? did it work w/o reboot? I am going to do something similar and want to check .

[Matti_Kurkela]

I seem to have missed the request for examples originally...sorry.

For example, some older FibreChannel HBA driver module versions may need module parameters to work optimally with the SAN fabric. But if your root filesystem is on SAN storage, you cannot unload the HBA driver while the system is running, because that would require unmounting the root filesystem first.

And because the FibreChannel driver is required to mount the root filesystem, it is included in the initrd file. Unless you use the mkinitrd command to recreate the initrd file for your kernel, your new settings will be ignored in your next and subsequent reboots, because the initrd still uses an old information that was copied from the modprobe.conf file into the initrd file when it was originally created. When you install an updated kernel package, a new initrd file will be automatically created, and it will include the current modprobe.conf file.

Another example: if you need to change the module options of a NIC module and have console access (either local or iLO) to the system, you can definitely use ifdown to shut down all network interfaces, unload the appropriate module, then reload it (or rather, verify that the "ifup" command will be able to load it automatically) and re-enable the NICs, without rebooting. However, some applications may need to be stopped for this procedure.

You may be able to change some module parameters dynamically using the /sys/module/<module-name>/parameters/ directory, but changing the parameters this way does not make them persistent: the changes will be lost as you reboot the system.

Whenever you change modprobe.conf, rebooting the system is a good test to make sure the system is bootable with the new configuration. This is very important when the system is booted very rarely: if you make a mistake, you might accidentally be leaving the system in an unbootable condition without knowing it.

(A fellow sysadmin was once installing an errata kernel that was supposed to fix a known problem. But afterwards, the system failed to reboot with the new kernel, with a big spew of error messages before even mounting the root filesystem. The old kernels were OK. The cause was a typo in the modprobe.conf file: the initrd of the old kernel was created before the typo was made, so it worked.  The typo in the modprobe.conf file caused the mkinitrd script to include a syntax error in the auto-generated init script included within the initrd file, causing the boot to fail rather spectacularly. The error was caused by

Spoiler

having two "options" lines in modprobe.conf for the same scsi_hostadapter module in RHEL4.)