Description of problem: This is similar to bug 360111. mkdumprd uses the following script fragment to determine the volume group associated with a logical volume: VGRP=`lvm lvs | grep $i | cut -d" " -f4` Where $i has been initialised to the name of the logical volume. This doesn't work very well in the case that the same LV name exists in multiple VGs since VGRP will end up with a multi-line value (one line per VG/LV combination). E.g: +echo Scanning logical volumes Scanning logical volumes +lvm vgscan --ignorelockingfailure --mknodes Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 +echo Activating logical volumes Activating logical volumes +lvm vgchange -a y --ignorelockingfailure 2 logical volume(s) in volume group "VolGroup01" now active 2 logical volume(s) in volume group "VolGroup00" now active +DM_NUM=0 +VGRP=VolGroup00 ^^^^^^^^^^^^^^^^^^^^^^ VolGroup01 ^^^^^^^^^^^^^^^^^^^^^^^ +mkdir -p /dev/VolGroup00 VolGroup01 +[ ! -e /dev/VolGroup00 VolGroup01/LogVol00 ] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [: VolGroup01/LogVol00: unknown operand +VGRP=VolGroup00 VolGroup01 +mkdir -p /dev/VolGroup00 VolGroup01 +[ ! -e /dev/VolGroup00 VolGroup01/LogVol01 ] [: VolGroup01/LogVol01: unknown operand +VGRP=VolGroup00 VolGroup01 +mkdir -p /dev/VolGroup00 VolGroup01 +[ ! -e /dev/VolGroup00 VolGroup01/LogVol00 ] [: VolGroup01/LogVol00: unknown operand +VGRP=VolGroup00 VolGroup01 +mkdir -p /dev/VolGroup00 VolGroup01 +[ ! -e /dev/VolGroup00 VolGroup01/LogVol01 ] [: VolGroup01/LogVol01: unknown operand Version-Release number of selected component (if applicable): kexec-tools-1.101-194.4.el5 How reproducible: 100% Steps to Reproduce: 1. Configure a system having at least two VGs containing identically named LVs. E.g. VolGroup00/LogVol00 and VolGroup01/LogVol01 (actual names are not important) 2. Configure kdump 3. Attempt to kdmump or run mkdumprd & inspect generated script. Actual results: Making device-mapper control node Scanning logical volumes Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 Activating logical volumes 2 logical volume(s) in volume group "VolGroup01" now active 2 logical volume(s) in volume group "VolGroup00" now active [: VolGroup01/LogVol00: unknown operand ^^^^^^^^^^^^^^^^^^^^^ [: VolGroup01/LogVol01: unknown operand [: VolGroup01/LogVol00: unknown operand [: VolGroup01/LogVol01: unknown operand Expected results: Volume groups correctly activated. No error messages. Additional info:
Created attachment 270141 [details] proposed patch for mkdumprd
Not really related to this bug, but why do we have these lines in the script? ln -s /dev/mapper/\$VGRP-\$i /dev/dm-\$DM_NUM" The dm-N nodes shouldn't get created these days (they are internal device-mapper names for the devices, rather than the ones that appear under /dev/mapper). In RHEL5, the default udev config will never create them: # grep -r dm- /etc/udev/rules.d/ /etc/udev/rules.d/50-udev.rules:KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device"
Created attachment 270161 [details] revised patch slight modification to the original patch: - use --noheadings and -o lv_name,vg_name instead of awk'ing the default output. - don't create dm-N nodes in /dev
Answering my own question in comment #3 I'm assuming this is a left-over from earlier Fedora releases where the ignore_device udev rule didn't exist.
Have you tested the patch in coment #4 against kexec-tools-1.102pre-7? If so, its fine with me. Let me know how the testing goes and I'll incorporate it.
Tested against kexec-tools-1.102pre-8 with good results on a system that failed with the old mkdumprd: Making device-mapper control node Scanning logical volumes Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "my-vg" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 Activating logical volumes 2 logical volume(s) in volume group "VolGroup01" now active 1 logical volume(s) in volume group "my-vg" now active 2 logical volume(s) in volume group "VolGroup00" now active Attempting to enter user-space to capture vmcore Creating root device. Checking root filesystem. fsck 1.38 (30-Jun-2005) ...
once I have a pm-ack on this, I'll check it in.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
I'm rolling this bug into 360111 as both patches affect the same code for different variations of the same problem *** This bug has been marked as a duplicate of 360111 ***