From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
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
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".
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):
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.
See problem description.
I think this one has to be tackled within the installer:
LVM2 doesn't let you create a volume group named XYZ if /dev/XYZ
already exists - but during installation I believe /dev is pretty empty.
Added "root" to the blacklist of vg names.
Thanks for treating this as an actual problem. Just wondering: Is this
blacklist checked for potential conflicts on an upgrade, or only on a