Bug 401711 - mkdumprd does not cope with duplicate LV names
mkdumprd does not cope with duplicate LV names
Status: CLOSED DUPLICATE of bug 360111
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 14:46 EST by Bryn M. Reeves
Modified: 2008-03-18 07:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-18 07:07:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch for mkdumprd (1.30 KB, patch)
2007-11-27 14:59 EST, Bryn M. Reeves
no flags Details | Diff
revised patch (1.25 KB, patch)
2007-11-27 15:08 EST, Bryn M. Reeves
no flags Details | Diff

  None (edit)
Description Bryn M. Reeves 2007-11-27 14:46:50 EST
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:
Comment 1 Bryn M. Reeves 2007-11-27 14:59:53 EST
Created attachment 270141 [details]
proposed patch for mkdumprd
Comment 3 Bryn M. Reeves 2007-11-27 15:02:48 EST
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"
Comment 4 Bryn M. Reeves 2007-11-27 15:08:02 EST
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
Comment 5 Bryn M. Reeves 2007-11-28 04:55:12 EST
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.
Comment 6 Neil Horman 2007-11-28 08:53:38 EST
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.
Comment 7 Bryn M. Reeves 2007-12-06 09:10:10 EST
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)
...
Comment 8 Neil Horman 2007-12-06 09:30:43 EST
once I have a pm-ack on this, I'll check it in.
Comment 9 RHEL Product and Program Management 2008-01-02 09:44:36 EST
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.
Comment 10 RHEL Product and Program Management 2008-03-11 15:37:22 EDT
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.
Comment 11 Neil Horman 2008-03-18 07:07:45 EDT
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 ***

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