Bug 174678 - Install failed /bin/lvm exited abnormally
Summary: Install failed /bin/lvm exited abnormally
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mkinitrd   
(Show other bugs)
Version: 4.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
Blocks: 181409
TreeView+ depends on / blocked
Reported: 2005-12-01 10:56 UTC by Bastien Nocera
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2006-0315
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 21:10:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mkinitrd-mapper-support.patch (878 bytes, patch)
2005-12-01 10:56 UTC, Bastien Nocera
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0315 normal SHIPPED_LIVE mkinitrd bug fix update 2006-08-09 04:00:00 UTC

Description Bastien Nocera 2005-12-01 10:56:28 UTC
Same problem exists on RHEL4, Patch attached.

+++ This bug was initially created as a clone of Bug #154767 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050323
Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
Updated FC3 which had a pair of IDEs on lvm2 raid using striping.  Now won't boot.

linux ro root=/dev/mapper/spare_vg-lvol0
Making device-mapper control node
Scanning logical volumes
Reading all physical volumes...
Found volume group "spare_vg" using metadata type lvm2
Found volume group "system" using metadata type lvm2
Activating logical volumes
Unable to find volume group "mapper"
Error: /bin/lvm exited abnormally
... panic

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

How reproducible:

Steps to Reproduce:
1. boot

Additional info:

-- Additional comment from katzj@redhat.com on 2005-04-14 17:17 EST --
Can you provide /root/upgrade.log and /var/log/anaconda*?

-- Additional comment from ndbecker2@verizon.net on 2005-04-14 20:20 EST --
Created an attachment (id=113202)

-- Additional comment from pjones@redhat.com on 2005-04-20 14:54 EST --
Did "root=/dev/mapper/spare_vg-lvol0" work before the upgrade?  It looks as if
you should be using "root=/dev/spare_vg/lvol0".

-- Additional comment from ndbecker2@verizon.net on 2005-04-20 16:53 EST --
Dunno, but I can boot using FC4Test2 rescue, and it shows 
that /dev/mapper/spare_vg-lvol0 is mounted fine. 

-- Additional comment from katzj@redhat.com on 2005-04-27 14:46 EST --
From rescue mode, can you get the output of /sbin/mkinitrd -v -f /tmp/foo.img
kernelver?  It looks like it's getting confused about what volumes it should be
activating.  Also, what does /etc/fstab look like?

-- Additional comment from ndbecker2@verizon.net on 2005-04-27 19:15 EST --
Created an attachment (id=113747)

-- Additional comment from ndbecker2@verizon.net on 2005-04-27 19:16 EST --
Created an attachment (id=113748)
mkinitfd output

-- Additional comment from katzj@redhat.com on 2005-05-05 17:15 EST --
This looks like it has to do with how mkinitrd resolves the volume name.  We
always specify the LV as /dev/vg/lv instead of the /dev/mapper/vg-lv name so
that we can determine vg and lv easily.  

-- Additional comment from j.w.r.degoede@hhs.nl on 2005-05-06 03:44 EST --
I have this exact same problem, the problem is indeed how the volume name is
resolved by mkinitrd, the line which does this in mkinitrd is:
root_vg=$(echo $rootdev | cut -d/ -f3)

Which will give "mapper" when rootdev is /dev/mapper/xxx. Note that a rootdev of
/dev/mapper/xx used to be supported as seen a couple of lines below:
if echo $rootdev |grep -q /dev/mapper 2>/dev/null ; then root_lvm=1 ; fi

So I changed this line to:
    if echo $rootdev |grep -q /dev/mapper 2>/dev/null ; then
        root_vg=$(echo $rootdev | cut -d/ -f4)

This however still doesn't work since since my root is on
/dev/mapper/Volume00-Root and this resolves root_vg to Volume00-Root . 
Where it should be Volume00. We could do a cut -d - -f 1 on this, but do the
devices in /dev/mapper always have the form of Volume-ID?

I did create my grub.conf manually as I moved FC 2 from an old disk with plain
ext3 to a new disk with lvm2 -> ext3. So hopefully this won't bite to many
people but there are now at least 2 people who were bitten by this and have gone
trough to trouble to bugzilla this.

-- Additional comment from katzj@redhat.com on 2005-05-18 15:53 EST --
Peter fixed this; should be in 4.2.13 or later

-- Additional comment from j.w.r.degoede@hhs.nl on 2005-05-28 13:03 EST --
I can verify that this has been fixed (for me) in mkinitrd-4.2.15 . I think this
can be closed now.

Comment 1 Bastien Nocera 2005-12-01 10:56:29 UTC
Created attachment 121674 [details]

Comment 2 James Laska 2006-03-22 21:31:39 UTC
Patch provided and positive test results against patch are in ... adding QE ACK
for U4.

Comment 5 Bob Johnson 2006-04-11 16:46:11 UTC
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

Comment 8 Red Hat Bugzilla 2006-08-10 21:10:45 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 the 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.