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:
Always

Steps to Reproduce:
1. boot
2.
3.
  

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)
logs


-- 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)
fstab


-- 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)
        root_lvm=1
    fi

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.