Description of problem: mkdumprd utility hangs due to different dependencies in realtime and kdump kernel Version-Release number of selected component (if applicable): Kdump kernel: 2.6.32-358.el6.x86_64 RHEL6.4 Current kernel: 3.2.33-rt50.66.el6rt.x86_64 kexec-tools-2.0.0-258.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure kdump as described in documentation. (+ use --builtin option if needed) 2. Execute 'service kdump start' to make kdump image. Actual results: Command hangs at mkdumprd script. Expected results: Successfully build image for kdump. Additional info: mkdumprd script hangs on resolving dependences in function depsolve_modlist. This function use list of current loaded kernel modules (and explicitly defined in mkdumprd options) to resolve dependencies. The problem is that in realtime and kdump kernel one module can have different dependencies. For example in kdump kernel two modules 'scsi_transport_fc' and 'qla2xxx' has 'scsi_tgt' module as dependency, but in realtime kernel there is no one. So in the list of loaded modules with realtime kernel there is no 'scsi_tgt' module and function depsolve_modlist hangs. There is a workaround: one can explicitly add needed module to list in option in /etc/sysconfig/kdump wit option '--preload': MKDUMPRD_ARGS="-v --builtin=acpi-power-meter --builtin=joydev --preload=scsi_tgt" It should be noted that there are two similar bugs (719105 and 626606) with hangs but all patches from bugs are also applied to affected versions on mkdumprd.
I'm reassigning this to kexec-tools in RHEL6 (just like bug #719105 and bug #626606) as this is a problem of mkdumprd, not of the realtime kernel.
(In reply to comment #2) > I'm reassigning this to kexec-tools in RHEL6 (just like bug #719105 and bug > #626606) as this is a problem of mkdumprd, not of the realtime kernel. Ok, thanks, It is my mistake to assign it to kernel-rt.
Since MRG-2.1 the MRG realtime kernel can be used as the kdump kernel. We also provide a script to simplify kdump configuration, /usr/bin/rt-setup-kdump, part of the rt-setup package. As the MRG realtime kernel versions change rather drastically when compared to RHEL, it is expected that from time to time kernel module names may change and and new modules are introduced. The current mkdumprd tool in RHEL6 sometimes has problems to deal with modules present in the running kernel that are not available (either unavailable or built-in) in the requested kdump kernel. A request for enhancement has already been filled but due to the possible impact, this process requires a very thorough testing on all supported platforms and may take some time to be finished. Meanwhile, the suggestion is to boot the MRG realtime kernel and run /usr/bin/rt-setup-kdump. Please make sure you have the latest rt-setup version installed.
Thank you for information. I just follow instructions from doc: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/2/html-single/Realtime_Tuning_Guide/index.html#sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_kdump_and_kexec_with_the_RT_kernel There is statement that "MRG Realtime uses the stock Red Hat Enterprise Linux 6 kernel as the kdump kernel" so I use stock kernel. Is rt kernel officially supported for kdump since MRG 2.1?
Please have a look at this URL: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/2/html/Technical_Notes/RHBA-2012-1492.html These are the Technical Notes for Errata RHBA-2012-1492. I had the impression the notes were already on the guides but I was wrong. The Documentation Team is already looking at the necessary changes.
Good, Thanks.
The MRG Realtime Tuning Guide has been updated to reflect that the Realtime kernel is now the preferred kdump crash kernel on MRG 2.1 and later. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/2/html-single/Realtime_Tuning_Guide/index.html#sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_kdump_and_kexec_with_the_RT_kernel
Mikhail, can we close this issue now that the Tuning Guide has been correctly updated?
Yes, I think we can close this issue. Thank you.
Thank you for your confirmation!