Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 472915

Summary:

mkdumprd hates new mdadm.conf layout, then hangs even once its fixed

Product:

Red Hat Enterprise Linux 5

Reporter:

Jarod Wilson <jarod>

Component:

kexec-tools

Assignee:

Neil Horman <nhorman>

Status:

CLOSED DUPLICATE

QA Contact:

Martin Jenner <mjenner>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

5.4

CC:

qcai

Target Milestone:

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2009-01-10 14:40:36 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
patch to get raid modules more easily	none

Description Jarod Wilson 2008-11-25 16:10:56 UTC

Description of problem:
Seems something changed in the way mdadm.conf gets written out in 5.3, as I have a cleanly installed 5.3-ish system with the following mdadm.conf contents:

# mdadm.conf written out by anaconda
DEVICE partitions
MAILADDR root
ARRAY /dev/md1 level=raid1 num-devices=2 uuid=4da5c52a:...:64b31684
ARRAY /dev/md2 level=raid1 num-devices=2 uuid=a023103c:...:22ca919f
ARRAY /dev/md0 super-minor=0

(uuids shortened to prevent line-wrapping)

The last entry causes mkdumprd to puke, like so:
# mkdumprd -v ...
[...]
Looking for deps of module ARRAY
No module ARRAY found for kernel 2.6.18-124.el5, aborting.

Altering the md0 entry to look more like the others (ARRAY /dev/md0 level=raid1 num-devices=2 super-minor=0), I no longer hit that problem, but mkdumprd still encounters an indefinite hang.


# mkdumprd -v -f /boot/initrd-2.6.18-124.el5kdump.img 2.6.18-124.el5
Creating initramfs
Looking for deps of module ata_piix: libata scsi_mod
Looking for deps of module libata: scsi_mod
Looking for deps of module scsi_mod
Looking for deps of module sd_mod: scsi_mod
Looking for deps of module ahci: libata scsi_mod
Looking for deps of module ide-disk
Looking for deps of module ext3: jbd
Looking for deps of module jbd
Found RAID component md1
Looking for deps of module raid1
Looking for driver for device sdb2
Looking for driver for device sda2
Using modules: /lib/modules/2.6.18-124.el5/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.18-124.el5/kernel/drivers/scsi/sd_mod.ko /lib/modules/2.6.18-124.el5/kernel/drivers/ata/libata.ko /lib/modules/2.6.18-124.el5/kernel/drivers/ata/ata_piix.ko /lib/modules/2.6.18-124.el5/kernel/drivers/ata/ahci.ko /lib/modules/2.6.18-124.el5/kernel/fs/jbd/jbd.ko /lib/modules/2.6.18-124.el5/kernel/fs/ext3/ext3.ko /lib/modules/2.6.18-124.el5/kernel/drivers/md/raid1.ko
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/scsi/scsi_mod.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/scsi_mod.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/scsi/sd_mod.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/sd_mod.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/ata/libata.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/libata.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/ata/ata_piix.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/ata_piix.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/ata/ahci.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/ahci.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/fs/jbd/jbd.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/jbd.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/fs/ext3/ext3.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/ext3.ko' [elf64-x86-64]
copy from `/lib/modules/2.6.18-124.el5/kernel/drivers/md/raid1.ko' [elf64-x86-64] to `/tmp/initrd.TP7904/lib/raid1.ko' [elf64-x86-64]
<hangs indefinitely here>


Version-Release number of selected component (if applicable):
kernel-2.6.18-124.el5
mdadm-2.6.4-1.el5
kexec-tools-1.102pre-50.el5

Comment 1 Neil Horman 2008-12-17 14:29:24 UTC

Jarod, could you please run the following command on this system:
mdadm --examine --scan
for me please nad post the output in this bug. Thanks!

Comment 2 Jarod Wilson 2008-12-17 14:37:10 UTC

Sure, here it is:

# mdadm --examine --scan
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=29e76d93:105cd385:a143a3e6:bd3dc982
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=4da5c52a:0c6392c6:b4c85bb1:64b31684
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=a023103c:a09bf8ca:a30ff734:22ca919f

Comment 3 Neil Horman 2008-12-17 15:52:04 UTC

Created attachment 327263 [details]
patch to get raid modules more easily

copy that, thank s jarod.  This patch should fix you.  Please test and confirm, and I'll get it in for 5.4

Comment 4 Jarod Wilson 2008-12-18 02:00:58 UTC

Golden. Ship it!

Comment 5 Jarod Wilson 2008-12-18 02:03:29 UTC

nb: the earlier hang is also somewhat inexplicably gone now too, but hey, I'll take it. Was hitting the hang even after twiddling mdadm.conf to give me more or less the exact same thing this change does, so *shrug*.

Comment 6 Neil Horman 2009-01-10 14:40:36 UTC

closing this as a dup of 479211 as there is a merged patch for both of these issues there

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