- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: changes to modprobe.conf
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-21-2011 08:08 AM
03-21-2011 08:08 AM
changes to modprobe.conf
(what about depmod??)
Thanks
Joe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-21-2011 11:55 PM
03-21-2011 11:55 PM
Re: changes to modprobe.conf
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-22-2011 06:22 AM
03-22-2011 06:22 AM
Re: changes to modprobe.conf
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-24-2012 07:28 AM
06-24-2012 07:28 AM
Re: changes to modprobe.conf
What change were u making ? did it work w/o reboot? I am going to do something similar and want to check .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-25-2012 12:50 AM
06-25-2012 12:50 AM
Re: changes to modprobe.conf
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