From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: mkinitrd's logic is incorrect when root is on a logical volume. it assumes that the device file is going to reside in /dev and consequently fails. some hardware, like compaq/hp dl-series servers use the cpqarray or cciss array controllers, and their device files reside in /dev/cciss instead of directly in /dev, etc. this was also a bug in 8.0 the quickie patch that implements a first-cut at the solution follows: # diff -u /sbin/mkinitrd.orig /sbin/mkinitrd --- /sbin/mkinitrd.orig 2003-04-15 14:51:39.000000000 -0400 +++ /sbin/mkinitrd 2003-04-15 14:51:55.000000000 -0400 @@ -535,7 +535,7 @@ if [ -n "$root_lvm" ]; then pvs=$(/sbin/lvmdiskscan |grep "0x8E" | /bin/awk {'print $3;'}) for pv in $pvs; do - cp -a $pv $MNTIMAGE/$pv + cp --parents -a $pv $MNTIMAGE/$pv done inst /sbin/vgwrapper "$MNTIMAGE/bin/vgwrapper" Version-Release number of selected component (if applicable): mkinitrd-3.4.42-1 How reproducible: Always Steps to Reproduce: 1. create root on a LVM with a piece of equipment whose physical volume is not directly in /dev, like on a compaq dl360, etc. 2. try to recreate the initrd 3. cry Actual Results: it fails because the device doesn't exist in /dev and the initrd doesn't get created properly. Expected Results: it should work ;) Additional info: description should cover it.
Fixed in 3.5.51
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks.