Red Hat Bugzilla – Bug 459614
kdump's dumprd not rebuilding when appropriate.
Last modified: 2011-01-24 18:16:30 EST
Description of problem:
kdump's initrd not rebuilt after updating:
- kdump_pre script
- any of the extra_modules
Version-Release number of selected component (if applicable):
Steps to Reproduce:
for any of the required components listed in /etc/kdump.conf:
- touch the component
- restart kdump service
- check whether the dumprd is rebuilt with the touched component. 1.
dumprd rebuilt after touching kdump_post script
dumprd not rebuilt after touching kdump_pre script
dumprd rebuilt after touching kernel
dumprd not rebuilt after touching a module
dumprd rebuilt in all cases.
Created attachment 314642 [details]
patch to check stamps on other file
This should suck in the extra files that need checking. Please test and confirm. the kernel image was already included in that list however. CAn you tell me a bit more about what file you touched, how you verified the timestamp was modified and what you observed when the kdump service was restarted.
- touch an input file
- service kdump restart
- kdump_pre script is properly checked
- kdump_post script is properly checked
- extra_bins was not tested, but I see no reason to think the same change wouldn't work here
These changes are definitely worth taking.
- extra_modules does not work as expected. Listing any extra module causes a dumprd rebuild.
I think the problem is because the kernel modules are referenced by name and not by path. There's also a subtlety here that modules.dep should be traversed to check dependencies.--otherwise updating the dependency will not trigger rebuilding the dumprd.
- extra_modules does not work as expected. Listing any extra module causes a
Not sure what you mean by that? Did you mean to say that it does _not_ cause a rebuild? Or does it cause a rebuild when it should not?
What I meant was that date_check for the extra_modules needs to be more sophisticated.
Modules are listed by module name, not file path--not the least because the path is dependent on the kernel version. For example:
references kernel module file:
Treating the extra_modules as files as in:
+ CHECK_FILE=`grep ^extra_modules $KDUMP_CONFIG_FILE | cut -d\ -f2-`
+ EXTRA_FILES="$EXTRA_FILES $CHECK_FILE"
causes the dumprd to be rebuilt every time the kdump service is started because the file "ipmi_msghandler" does not exist.
The trace is:
#> service kdump restart
Stopping kdump: [ OK ]
Detected change(s) the following file(s):
Starting kdump: [ OK ]
(In reply to comment #4)
> What I meant was that date_check for the extra_modules needs to be more
IOW, /lib/modules/$(uname -r)/modules.dep is rquired to dereference module names and dependencies.
for mod in $extra_modules
mod_ref=$(grep "/$mod.ko:" /lib/modules/$(uname -r)/modules.dep)
mod_file=$(echo $(mod_ref) | cut -d':' -f1)
mod_deps=$(echo $(mod_ref) | cut -d':' -f2)
#...recursively check $mod_deps
Or if it's a safe assumption that modules.dep is updated everytime a module is changed, then the following might suffice at the expense of an occasion unnecessary rebuild.
if [ "$(grep '^extra_modules' KDUMP_CONFIG_FILE | cut -d\ -f2- ) -ne "" ]
EXTRA_FILES="$EXTRA_FILES /lib/modules/$(uname -r)/modules.dep
I think perhaps the safest thing to do is look to see if extra_modules is non-null and rebuild if it has anything listed. Its overkill, but it saves us having to worry about wierd cases, like if someone has a 3rd parth module that doesn't update the dep tree or some such.
I've checked this and the extra_modules detection into -35.el5.
yes, already reported, slated to be fixed in 5.4
*** Bug 474365 has been marked as a duplicate of this bug. ***
*** Bug 471306 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.