Red Hat Bugzilla – Bug 657805
Anaconda fails to activate all logical volumes during upgrade
Last modified: 2010-12-03 01:20:48 EST
Created attachment 463292 [details] Anaconda traceback after failure. Description of problem: During an installation upgrade on my system with 12 LVs within a single VG, only 5 of the LVs were activated during stage 2 of the upgrade process. This caused the upgrade to fail, as it could not mount /usr which was one of the inactive LVs. Version-Release number of selected component (if applicable): Anaconda 14.22 for Fedora 14 x86_64 installation. How reproducible: 100% on the system with problem. Steps to Reproduce: 1. Boot kernel and install.img from installation DVD through grub, to make use of Everything repo rather than DVD repo, from a local disk. This configuration has run fine on other systems. 2. Step through stage 1 and select upgrade in stage 2. 3. When an error dialogue appears type Ctl-Alt-F2 and examine setup with lmv lvs, etc, and see that only 5 LVs are available. Actual results: Actual error in this case was that /usr/tmp was not symlinked to /var/tmp. The cause was that /usr was not mounted. Only 5 of the 12 LVs were active. Expected results: Correctly activate all LVs, mount them and run through installation process. Additional info: At this sage killall -USR2 anaconda was run and logs saved for further investigation (attached). Preliminary investigation seems to indicate that while the LVs were seen early in the Storage process (blkid.tab) not all were found when searching for matching UUIDs.
I've been looking a this further and wondering if it is related to the updates to udev/libudev in bugzilla report #652318. The basic problem can be seen around line 5128 of the anaconda traceback log, where the VG is added to the DeviceTree and has the LV names as 'LVM2_LV_NAME': ['archive', 'squid', 'maildir', 'srv', 'share', 'archive', 'srv', 'archive', 'srv', 'archive', 'srv', 'archive'] i.e. duplicated of existing entries, as are the entries for LVM2_LV_UUID and LVM2_LV_SIZE. The version of libudev on the install disk seems to be older than the patch listed above, which seems to relate to the issue I'm seeing.
Created attachment 463704 [details] udevadm info --export-db output Okay, so it looks like it may not be anaconda directly with a problem here. I ran "udevadm info --export-db" and it also shows the same issue with the raw udev data. So the problem is with the install image, but with some of the other parts.
*** This bug has been marked as a duplicate of bug 652318 ***
Just to add a final comment, I updated udevd in the boot initrd.img (not the one in install.img) and it corrected the problem. So, yes it is a udevd bug.