Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154767 - Install failed /bin/lvm exited abnormally
Summary: Install failed /bin/lvm exited abnormally
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 4
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
Reported: 2005-04-14 01:20 UTC by Neal Becker
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-27 21:10:59 UTC

Attachments (Terms of Use)
logs (deleted)
2005-04-15 00:20 UTC, Neal Becker
no flags Details
fstab (deleted)
2005-04-27 23:15 UTC, Neal Becker
no flags Details
mkinitfd output (deleted)
2005-04-27 23:16 UTC, Neal Becker
no flags Details

Description Neal Becker 2005-04-14 01:20:29 UTC
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:

Comment 1 Jeremy Katz 2005-04-14 21:17:13 UTC
Can you provide /root/upgrade.log and /var/log/anaconda*?

Comment 2 Neal Becker 2005-04-15 00:20:44 UTC
Created attachment 113202 [details]

Comment 3 Peter Jones 2005-04-20 18:54:51 UTC
Did "root=/dev/mapper/spare_vg-lvol0" work before the upgrade?  It looks as if
you should be using "root=/dev/spare_vg/lvol0".

Comment 4 Neal Becker 2005-04-20 20:53:22 UTC
Dunno, but I can boot using FC4Test2 rescue, and it shows 
that /dev/mapper/spare_vg-lvol0 is mounted fine. 

Comment 5 Jeremy Katz 2005-04-27 18:46:13 UTC
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?

Comment 6 Neal Becker 2005-04-27 23:15:03 UTC
Created attachment 113747 [details]

Comment 7 Neal Becker 2005-04-27 23:16:26 UTC
Created attachment 113748 [details]
mkinitfd output

Comment 8 Jeremy Katz 2005-05-05 21:15:55 UTC
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.  

Comment 9 Hans de Goede 2005-05-06 07:44:56 UTC
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.

Comment 10 Jeremy Katz 2005-05-18 19:53:29 UTC
Peter fixed this; should be in 4.2.13 or later

Comment 11 Hans de Goede 2005-05-28 17:03:26 UTC
I can verify that this has been fixed (for me) in mkinitrd-4.2.15 . I think this
can be closed now.

Comment 12 Wade Mealing 2006-01-18 04:43:00 UTC
Is this fixed for RHEL4 and if so, which version ?

Comment 13 Charlie Brady 2006-01-18 20:18:20 UTC
> Is this fixed for RHEL4 and if so, which version ?

Doesn't seem to have been. Try this patch:

--- mkinitrd-   2005-08-29 16:32:12.000000000 -0400
+++ mezzanine_patched_mkinitrd- 2006-01-18 15:11:42.000000000 -0500
@@ -487,7 +487,11 @@
     basicmodules="$basicmodules -${loopFs}"
 # check if the root fs is on a logical volume
 elif ! echo $rootdev | cut -c1-6 |grep -q "LABEL=" ; then
-    root_vg=$(echo $rootdev | cut -d/ -f3)
+    if echo $rootdev | grep -q /dev/mapper 2>/dev/null; then
+        root_vg=$(echo $rootdev | cut -d/ -f4 | cut -d- -f1)
+    else
+        root_vg=$(echo $rootdev | cut -d/ -f3)
+    fi
     rootdev=$(echo "readlink $rootdev" | /sbin/nash --quiet)
     major=`ls -l $rootdev | sed -e "s/.* \\([0-9]\+\\), *[0-9]\+.*/\\1/"`
     [ "$major" != "58" ] || root_lvm=1

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