From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
I had a perfectly serviceable FC2 install that I upgraded to FC3. This
install had /boot as a primary partition and everything else in
logical volumes in an lvm volume group called "root". Thus, for
example, when running the system would have /dev/root/root mounted on
/ and /dev/root/usr mounted on /usr, but /dev/hda1 mounted on /boot.
After upgrading to FC3, the system would not boot -- it would make it
into the initrd's init script, start having problems at the mkrootdev
/dev/root (mknod failed 17), which continued with the root mount
(error 15 mounting ext3), culminating in a panic at the umount of
/initrd/dev.

After much fooling around with rescue mode on the boot cd (thanks much
for such an excellent tool) I, with the help of some co-workers,
concluded that the problem stemmed from the fact that my volume group
was named "root". To fix it, I

(a) booted under the rescue cd, edited /etc/fstab to refer to the
logical volume devices as "/dev/rootlv/<fsname>", and edited
/etc/grub.conf to refer to "root=/dev/rootlv/root".

(b) rebooted under the rescue cd *without mounting the system image
under /mnt/sysimage (choose "skip" at the appropriate time), ran the
lvm command "vgrename root rootlv".

(c) rebooted.

At this point all was well.

Also note that as part of my troubleshooting investigations, I set up
a fresh FC3 system (not upgraded from FC2) partitioned exactly the
same way as the problem system, thinking that I'd find out what how it
was supposed to look. Instead, I wound up reproducing the problem
exactly, except without involving an upgrade. Thus it is possible to
do an FC3 install that results in a system that will not boot simply
by a poor choice of volume group name.

I'd say that the simplest fix for this problem would be to simply have
a text warning in disk partitioning step telling people not to call
the volume group "root" (or any other predictable name in /dev), or
perhaps even to include logic preventing people from doing this.
Additionally, it might be possible to include logic in the upgrade
processing to detect this as a possible failure mode and work around
it, possibly by automating the vgrename.

Or, some might argue that there shouldn't be a dependancy like this,
but I figure that's going too far -- for example, one would probably
have similar problems resulting from naming a volume group "null".
Maybe, in the end, this is just a user headspace error -- I'm allowing
for this but am reporting it as much as anything to document this in
the knoweldge base. Still, it's a problem that didn't exist in FC2.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Set about to install FC3.
2. In disk partitioning, call your volume group "root"
3. finish the install and reboot.
    

Actual Results:  System panics on boot.

Expected Results:  Normal boot.

Additional info:

See problem description.