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 on 2005-04-14 17:17 EST -- Can you provide /root/upgrade.log and /var/log/anaconda*? -- Additional comment from ndbecker2 on 2005-04-14 20:20 EST -- Created an attachment (id=113202) logs -- Additional comment from pjones 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 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 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 on 2005-04-27 19:15 EST -- Created an attachment (id=113747) fstab -- Additional comment from ndbecker2 on 2005-04-27 19:16 EST -- Created an attachment (id=113748) mkinitfd output -- Additional comment from katzj 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 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 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 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] mkinitrd-mapper-support.patch
Patch provided and positive test results against patch are in ... adding QE ACK for U4.
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. http://rhn.redhat.com/errata/RHBA-2006-0315.html