Bug 657805

Summary: Anaconda fails to activate all logical volumes during upgrade
Product: [Fedora] Fedora Reporter: Frank Crawford <frank>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: anaconda-maint-list, frank, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-02 00:00:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Anaconda traceback after failure.
none
udevadm info --export-db output none

Description Frank Crawford 2010-11-28 05:15:38 UTC
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.

Comment 1 Frank Crawford 2010-11-28 11:38:08 UTC
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.

Comment 2 Frank Crawford 2010-11-30 11:59:13 UTC
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.

Comment 3 David Lehman 2010-12-02 00:00:38 UTC

*** This bug has been marked as a duplicate of bug 652318 ***

Comment 4 Frank Crawford 2010-12-03 06:20:48 UTC
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.