Bug 117410

When performing an upgrade installation from 9.3 to 10.0RC1, the system proceeds
through processing CD1 as normal. Upon reboot, the system stops booting with :

Waiting for /dev/LinuxVG/root to appear .... 

(LinuxVG is the name of the VG I'm using)

And then exits to a /bin/sh shell prompt after a few seconds. 

This behavior is reproducible on both x86_64 and i386 platforms, when using a VG
configuration created by 9.3 as follows:

/dev/hda1      Windows NTFS partition (~30GB)
/dev/hda2      ext2   /boot partition (~100mb)
/dev/hda3      LVM Physical volume (~50GB)

The /dev/hda3 Physical volume is assigned to VG "LinuxVG" with the following
logical volumes:

"root" (/dev/LinuxVG/root)   (~10GB, reiserfs)
"home" (/dev/LinuxVG/home)   (~4GB, ENCRYPTED, reiserfs)
"swap" (/dev/LinuxVG/swap)   (~2GB)

During installation, the new 2.6.13-8-default kernel is properly copied to /boot
and an initrd is created. However, the installation process fails (?) to
determine that the root volume is in LVM and thus does not copy "vgscan",
"vgchange" and LVM modules to the initrd.

I noticed this first on x86_64 but figured it was something strange on that
platform or perhaps my hardware, so I reinstalled that machine from scratch
without any other problems (deleted all linux partitions and started over). I
saw the exact same problem again on i386 tonight and spent a few more hours
diagnosing the problem.

Booting into rescue mode, I mounted the /dev/LinuxVG/* volumes under /mnt and
chroot'ed. Reissuing mkinitrd generated the same initrd that was already present
( no changes between the one generated by the install process and the manual one
 I made ). I validated that the contents of /etc/sysconfig/kernel:INITRD_MODULES
was correct as well (although it did not contain lvm, but checking with a
working 9.3 system also shows no lvm in that stanza).

Looking through mkinitrd, it seems that the code is failing to determine that
/dev/LinuxVG/root is indeed an LVM volume, and thus it fails to include the LVM
support in the initrd it creates. I tried to determine why it failed, but after
about an hour, I decided to look for a workaround instead. I changed the
"root_lvm=" line in the script to read "root_lvm=1" (eg always force lvm
support) and re-ran mkinitrd. 

A cursory examination of the initrd shows that "vgscan" and "vgchange" are now
copied into the initrd:/sbin, *BUT* they are copied as symlinks pointing to a
nonexistent "lvm" program. Checking the host revealed that "/sbin/vgchange ->
lvm" and "/sbin/vgscan -> lvm". I temporarily deleted the links and created real
copies of "lvm" for vgscan/vgchange. Re-running mkinitrd again copied the
correct binaries into the initrd image.

This results in an initrd that continues the installation cycle into
CD2,3,4,etc.. It (mkinitrd) does complain however about not being able to
determine the dependencies of "lvm-mod", which does not appear to even exist on
my system.

Let me know if you would like logs on this problem. For now, the workaround
seems to fix the problem and allows the installation to proceed -  I'm on CD4 now :)

-ml