Bug 657805 - Anaconda fails to activate all logical volumes during upgrade
Anaconda fails to activate all logical volumes during upgrade
Status: CLOSED DUPLICATE of bug 652318
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-11-28 00:15 EST by Frank Crawford
Modified: 2010-12-03 01:20 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-01 19:00:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Anaconda traceback after failure. (798.13 KB, text/plain)
2010-11-28 00:15 EST, Frank Crawford
no flags Details
udevadm info --export-db output (183.16 KB, text/plain)
2010-11-30 06:59 EST, Frank Crawford
no flags Details

  None (edit)
Description Frank Crawford 2010-11-28 00:15:38 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.
Comment 1 Frank Crawford 2010-11-28 06:38:08 EST
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 06:59:13 EST
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-01 19:00:38 EST

*** This bug has been marked as a duplicate of bug 652318 ***
Comment 4 Frank Crawford 2010-12-03 01:20:48 EST
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.

Note You need to log in before you can comment on or make changes to this bug.