Description of problem: mkdumprd fails while parsing my mdadm.conf file (enclosed). It seems to be looking for a RAID level number, which is not there and the fails, aborting creation of the initrd file. Version-Release number of selected component (if applicable): Fedora-13 kexec-tools.x86_64 2.0.0-36.fc13 mdadm.x86_64 3.1.2-10.fc13 How reproducible: TOTALLY with my mdadm.conf prior to installing VirtualBox and KVM. They have uncovered other latent bugs that seem to cause an earlier fail. Steps to Reproduce: 1. Have my /etc/mdadm.conf 2. rm -f /boot/initrd*kdump.img 3. service kdump start Actual results: No kdump initrd .... Rebuilding /boot/initrd... IN HANDLERAID No module ARRAY found for kernel... This aborts the attempt to Expected results: rebuild initrd Additional info: I'm running on a DELL T3500, with ICH10R fake raid controller, and two 1-TB SATA drives in a RAID-1 configuration. /dev/md127p1 is the boot partition and the rest of the RAID-1 (/dev/md127p2) is configured as an LVM PV. My /etc/mdadm.conf was generated at install time. Here it is $ cat /etc/mdadm.conf # mdadm.conf written out by anaconda MAILADDR root AUTO +imsm +1.x -all ARRAY /dev/md0 UUID=97a96c74:ad42f440:0a32a68e:41e25eaa ARRAY /dev/md127 UUID=3998c76c:0221a91e:7d4d5a$ more /etc/mdadm.conf
Another bug, I'll keep it in this bug report for now. I tried working around this problem by disabling the check for /etc/mdadm.conf. However, after that, mkdumprd tried to execute "nash" which is no longer available and generated an error message. Oddly enough, the initrd was in fact generated, unlike with the "no modue ARRAY found" error, but the image seems invalid since kdump still will not start.
please try using the mkdumprd I've attached in bz 629003. That should solve this problem
1) Tried the new script. It continued to fail when VirtualBox-OSE is installed as noted in https://bugzilla.redhat.com/show_bug.cgi?id=629003. 2) I removed VirtualBox and rebooted, but then got the "No module ARRAY found for kernel..." error message. 3) On a weird note, why is Bug #629012 an apparent clone of the one (#629013). Did I cause that? 4) I did notice that "nash" is no longer used in the script!
could you please send in your /etc/mdadm.conf file? Regarding bz 629012, yes, I think you created 2 bzs to track the same thing. You can close the other one if you like. I think what I'll do is figure out these two bugs (this and your hang, and then port it to RHEL6 and take the entire mkdumprd file into F-13 so we're back in step. That should take care of the nash business too.
*** Bug 629012 has been marked as a duplicate of this bug. ***
figured out what needs to be done to fix this from another reporter. I'll take care of this in the AM
kexec-tools-2.0.0-37.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kexec-tools-2.0.0-37.fc13
kexec-tools-2.0.0-37.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
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.
This seems to be still happening with kexec-tools 2.0.2 $ cat /etc/redhat-release Fedora release 16 (Verne) $ sudo mkdumprd --help usage: mkdumprd [--version] [--help] [-v] [-d] [-f] [--preload <module>] [--image-version] [--builtin=<module>] [--omit-dmraid] [--fstab=<fstab>] [--nocompress] <initrd-image> <kernel-version> (ex: mkdumprd /boot/initrd-2.2.5-15.img 2.2.5-15) $ cat /etc/mdadm.conf DEVICE partitions /dev/sd* MAILADDR XXXXX PROGRAM /root/bin/mdadm_failure ARRAY /dev/md/vg00 metadata=1.2 name=XXXXX:vg00 UUID=b15333fe:f7133c80:ce0d04a5:XXXXX spare-group=spares ARRAY /dev/md/backups metadata=1.2 name=XXXXXX:backups UUID=11525b8c:c9367523:16e56c4a:XXXXX spare-group=spares It also fails to recognize comments in the mdadm.conf -- I had to remove commented lines or I got an error about '#' or '#ARRAY' Jan 31 07:31:14 tendo kdumpctl[26518]: No kdump initial ramdisk found. Jan 31 07:31:14 tendo kdumpctl[26518]: Rebuilding /boot/initramfs-3.6.11-1.fc16.i686kdump.img Jan 31 07:31:30 tendo kdumpctl[26518]: No module ARRAY found for kernel 3.6.11-1.fc16.i686, aborting. Jan 31 07:31:30 tendo kdumpctl[26518]: Failed to run mkdumprd Jan 31 07:31:30 tendo kdump: mkdumprd: failed to make kdump initrd Jan 31 07:31:30 tendo systemd[1]: kdump.service: main process exited, code=exited, status=1 Jan 31 07:31:30 tendo systemd[1]: Unit kdump.service entered failed state.