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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
-- Additional comment from firstname.lastname@example.org on 2005-04-14 17:17 EST --
Can you provide /root/upgrade.log and /var/log/anaconda*?
-- Additional comment from email@example.com on 2005-04-14 20:20 EST --
Created an attachment (id=113202)
-- Additional comment from firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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 email@example.com on 2005-04-27 19:15 EST --
Created an attachment (id=113747)
-- Additional comment from firstname.lastname@example.org on 2005-04-27 19:16 EST --
Created an attachment (id=113748)
-- Additional comment from email@example.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 firstname.lastname@example.org 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 email@example.com on 2005-05-18 15:53 EST --
Peter fixed this; should be in 4.2.13 or later
-- Additional comment from firstname.lastname@example.org 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.
Created attachment 121674 [details]
Patch provided and positive test results against patch are in ... adding QE ACK
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.
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.