Bug 360111 - kdump not working with non-default LVM names
Summary: kdump not working with non-default LVM names
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools   
(Show other bugs)
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Red Hat Kernel QE team
: 401711 (view as bug list)
Depends On:
Blocks: 426269
TreeView+ depends on / blocked
Reported: 2007-10-31 12:46 UTC by Jan-Frode Myklebust
Modified: 2018-10-20 01:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 21:00:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
use awk instead of cut to find volume group (468 bytes, patch)
2007-10-31 13:24 UTC, Jan-Frode Myklebust
no flags Details | Diff
omnibus patch (1.19 KB, patch)
2008-03-18 11:15 UTC, Neil Horman
no flags Details | Diff
patch to correct multispace parsing error (778 bytes, patch)
2008-11-03 11:41 UTC, Neil Horman
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0105 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2009-01-20 16:04:36 UTC

Description Jan-Frode Myklebust 2007-10-31 12:46:52 UTC
Description of problem:

When triggering a kernel crash, kdump fails to find my logical volumes and then
doesn't save the crashdump.

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

kernel 2.6.18-8.1.15.el5

How reproducible:


Steps to Reproduce:
1. install a rhel5 system with all filesystems on lvm, using the follwing
anaconda script:
 clearpart --all --initlabel
 part /boot --fstype ext3 --size=128
 part pv.100000 --size=0 --grow
 volgroup rootvg --pesize=32768 pv.100000
 logvol /var --fstype ext3 --name=varlv --vgname=rootvg --size=3072
 logvol swap --fstype swap --name=swaplv --vgname=rootvg --size=2048
 logvol / --fstype ext3 --name=rootlv --vgname=rootvg --size=5120
 logvol /local --fstype ext3 --name=locallv --vgname=rootvg --size=1024

2. configure kdump to default to shell
3. crash it with echo c > /proc/sysrq-trigger
Actual results:

Fails to get a dump because during kdump initialization it can't find
/dev/mapper/-varlv, /dev/mapper/-swaplv, /dev/mapper/-rootlv.

Expected results:

It should find /dev/mapper/rootvg-varlv, /dev/mapper/rootvg-swaplv, etc.. and
give me a crash dump.

Additional info:

I checked the "init" script in the kdump initrd, and found the following section
 which seems to contain the bug:

for i in `lvm lvs | awk '{ if (NR > 1) print $1}'`

# loops over the following LV's: crashlv locallv projects rootlv swaplv varlv

   VGRP=`lvm lvs | grep $i | cut -d" " -f4`

Ouch! it's cut'ing on number of spaces. Only one of my LV's has long enough
names to only have 3 spaces in the output before the VG-name:

# for i in crashlv locallv machete projects rootlv swaplv varlv  ; do lvm lvs |
grep $i  ; done
  crashlv  rootvg -wi-ao  4.00G                              
  locallv  rootvg -wi-ao  1.00G                              
  machete  rootvg -wi-ao  9.78G                              
  projects rootvg -wi-ao 19.53G    # This is my only match!                   
  rootlv   rootvg -wi-ao  5.00G                              
  swaplv   rootvg -wi-ao  2.00G                              
  varlv    rootvg -wi-ao  3.00G          

A much better command for finding the VG-name would be:

   VGRP=`lvm lvs | grep $i | awk '{print $2}'`

# for i in crashlv locallv machete projects rootlv swaplv varlv  ; do lvm lvs |
grep $i | cut -d" " -f4 ; done


# for i in crashlv locallv machete projects rootlv swaplv varlv  ; do lvm lvs |
grep $i | awk '{print $2}' ; done

Comment 1 Jan-Frode Myklebust 2007-10-31 13:24:23 UTC
Created attachment 244531 [details]
use awk instead of cut to find volume group

Comment 2 Neil Horman 2007-12-19 21:58:25 UTC
seems good.  Thanks!

Comment 3 RHEL Product and Program Management 2008-01-02 14:44:41 UTC
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

Comment 4 RHEL Product and Program Management 2008-03-11 19:38:03 UTC
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 6 Neil Horman 2008-03-18 11:07:49 UTC
*** Bug 401711 has been marked as a duplicate of this bug. ***

Comment 7 Neil Horman 2008-03-18 11:15:02 UTC
Created attachment 298373 [details]
omnibus patch

This patch is the fix for both bz 360111 and 401711

Comment 8 Kevin Krafthefer 2008-05-22 16:03:44 UTC
This RFE has been reviewed during the RHEL RFE review
with Red Hat product management. This request has been *tentatively* approved
for inclusion
in the next update. This decision is not final and still pends further
technical review and scoping by Red Hat development engineering.

Comment 9 Neil Horman 2008-05-23 18:11:18 UTC
fixed in 1.102pre-22.el5

Comment 10 Jan-Frode Myklebust 2008-05-28 08:26:20 UTC
Where can I get 1.102pre-22.el5, and is it safe to use on production systems?

Manually fixing this on many servers is getting tedious... so I'd much rather
use this package if it's relatively safe.

Comment 11 Neil Horman 2008-05-28 11:18:44 UTC
Its not slated to be released until 5.3, so we won't support it yet on
productions systems.  If its important for you to have though, you can just
rebuild the -21 rpm from 5.2 with this patch included and run that on your
systems until then

Comment 14 Neil Horman 2008-11-03 11:41:25 UTC
Created attachment 322294 [details]
patch to correct multispace parsing error

Additional patch to test multispace parsing errors.  Please test and confirm that it fixes the problem.  Thanks!

Comment 16 Qian Cai 2008-11-04 02:12:31 UTC
Confirm it solves the problem in comment #13.

Comment 17 Neil Horman 2008-11-04 11:37:16 UTC
Thanks Cai!.  Comitted in -49.el5

Comment 22 errata-xmlrpc 2009-01-20 21:00:11 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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