Bug 719490 - mkdumprd fails to generate - no module array found for kernel
Summary: mkdumprd fails to generate - no module array found for kernel
Keywords:
Status: CLOSED DUPLICATE of bug 707805
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Cong Wang
QA Contact: Kernel Dump QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-07 02:24 UTC by Ayden Beeson
Modified: 2014-10-28 07:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the mkdumprd utility failed to parse the /etc/mdadm.cof configuration file. As a consequence, mkdumprd failed to create an initial ramdisk for kdump crash recovery and the kdump service failed to start. With this update, mkdumprd has been modified so that it now parses the configuration file and builds initrd correctly. The kdump service now starts as expected.
Clone Of:
Environment:
Last Closed: 2011-07-07 02:49:43 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Ayden Beeson 2011-07-07 02:24:01 UTC
Description of problem:
mkdumprd fails to build dump image when run, the error reported seems to indicate a problem parsing the mdadm.conf file.

My file has been manually regenerated using mdadm --detail --scan < /etc/mdadm.conf and so doesnt have some of the options generated by a "normal" generation, but is however perfectly suitable for use.

I have had a look at the source code (at http://webcache.googleusercontent.com/search?q=cache:lIbQkzFEzyEJ:web.mit.edu/~mkgray/afs/bar/sbin/mkdumprd+no+module+array+found+mkdumprd+rhel6&cd=9&hl=en&ct=clnk&gl=au&source=www.google.com.au) and it is using the following to generate the array lists:

for i in `cat /etc/mdadm.conf | grep "^[:space:]*[^#]" | grep ARRAY | sed -e's/\(^.*level=\)\(.*$\)/\2/' | cut -d" " -f1`;

My file has the following:
ARRAY /dev/md0 metadata=1.0 name=localhost.localdomain:0 UUID=7f38c153:a4bbcb06:92d4cf29:8892058f
ARRAY /dev/md1 metadata=1.2 name=anubis.homedomain:3 UUID=cf37f2b4:1c166f53:3acd9528:1409ded8
ARRAY /dev/md2 metadata=1.2 name=1 UUID=6d4009b9:1162c065:969b26ba:adc2dc02

(FYI, ignore the names, some were generated by anaconda, some after install)

As you can see, mine does not have the level in it, and seems to break it.

Version-Release number of selected component (if applicable): 5.0.39 (latest)


How reproducible: Everytime


Steps to Reproduce:
1. switch to root
2. attempt to start kdump (using service kdump start)
3. kdump attempts to create dump img, fails
  
Actual results:
fails with error:
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-131.4.1.el6.x86_64kdump.img
No module ARRAY found for kernel 2.6.32-131.4.1.el6.x86_64, aborting.
Failed to run mkdumprd

Expected results:
success in creating dump img, kdump starting successfully.

Additional info:
Again to repeat the above, i dont have a "system generated" mdadm.conf, and it does not show the levels. If this not a bug, please advise, it seems a bit strange however that it would work for the OS, but not for an app that depends on it. If you can advise another way to create the mdadm.conf that you would like me to test, please let me know.

Also, there were previous bugs sent in about this back in RHEL5 / FC13, and they had system generated mdadm.conf files that also did not contain the level.

One of those can be found at: https://bugzilla.redhat.com/show_bug.cgi?id=629013

As i dont have a system generated /etc/mdadm.conf that contains the level portion im unable to replicate a file that matches the layout expected. If you can advise how it should look i could replicate for testing.

Comment 2 Cong Wang 2011-07-07 02:49:43 UTC

*** This bug has been marked as a duplicate of bug 707805 ***

Comment 3 Miroslav Svoboda 2011-10-19 09:33:37 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the mkdumprd utility failed to parse the /etc/mdadm.cof configuration file. As a consequence, mkdumprd failed to create an initial ramdisk for kdump crash recovery and the kdump service failed to start. With this update, mkdumprd has been modified so that it now parses the configuration file and builds initrd correctly. The kdump service now starts as expected.


Note You need to log in before you can comment on or make changes to this bug.