Bug 846191 - Anaconda fails to find or activate LVM partitions when scanning storage devices during upgrade installation
Anaconda fails to find or activate LVM partitions when scanning storage devic...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-07 01:35 EDT by Scott Marshall
Modified: 2013-05-30 12:41 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-30 12:41:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Marshall 2012-08-07 01:35:59 EDT
Description of problem:
When booting Fedora 17 DVD to perform upgrade of existing Fedora 14, Fedora 15 or Fedora 16 systems (all configured using LVM2), anaconda fails to "find any existing partitions".  Nor does it find any when using the "Recover" mode.

Version-Release number of selected component (if applicable):
anaconda 16.25 (as displayed when booting from F17 DVD)

How reproducible:
Always

Steps to Reproduce:
1. Boot F17 DVD and select "Install/Upgrade"
2. F17 scans storage devices but does not present an existing environment to upgrade


  
Actual results:
Fedora (anaconda) fails to identify the existing environment contained inside the LVM partitions, and thus doesn't permit an upgrade instead assumes that it's a clean installation.

Expected results:
anaconda should detect the LVM partition, scan it, identify the VG and LVs within, and present the underlying installation for upgrade.

Additional info:

Filesystem (LVM) layout:
LVM Path	File System
rootvg/lv_root	/
rootvg/lv_home	/home
rootvg/lv_opt	/opt
rootvg/lv_usr	/usr
rootvg/lv_usrl	/usr/local
rootvg/lv_var	/var
rootvg/lv_varc	/var/cache
rootvg/lv_varl	/var/log
rootvg/lv_vars	/var/spool
rootvg/lv_swap0	SWAP

/dev/sda1	/boot
/dev/sda2	LVM2 partition

All LVM-based file systems are ext4.
/boot either ext2 or ext3



**** WORKAROUND ****
I've successfully been able to upgrade all the above systems to Fedora 17 by appending the following options to the Install/Upgrade vmlinuz command line:
rd_LVM_LV=rootvg/lv_root rd_LVM_LV=rootvg/lv_usr rd_LVM_LV=rootvg/lv_var

(FYI, these kernel loader options were already present in the grub configuration file for booting the older Fedora installations, so there's no reason why anaconda couldn't have used this to identify the correct LVM volumes during the scan phase.)

This seems to force anaconda to scan and activate the LVM VG and successfully mount the file systems so that the existing installation is presented as a candidate for upgrade.  From that point (assuming there is sufficient space in /usr), the usr merge script runs successfully, and the system upgrades to Fedora 17.

Before rebooting, I switched to a console screen, then chroot /mnt/sysimage and executed a "dracut -f" to ensure that the initial ram disk for the kernel was viable.

The reboot was then permitted and the system successfully booted a Fedora 17 environment.  I still needed to perform some package clean-ups due to the fact that I had some i686 packages installed for 32 bit support in my x86_64 installations.  These were not upgraded automatically (to be expected as they wouldn't have been present on the x86_64 DVD).
Comment 1 Scott Marshall 2012-08-07 02:18:57 EDT
I should clarify one thing here.  In my comment about the rd_LVM_LV options already being present in the grub configuration, the only option that had *ORIGINALLY* been present was the one specifying the location of the root file system.  I added the others during my various attempts to get a clean upgrade because when I manually added them to the anaconda upgrade command line, they new grub/grub2 configuration DID NOT save them.  It appears that the upgrade copied what was in the older kernel loader, and I failed to get a successful startup on reboot because the LVs for /var and /usr were not "pre-loaded", and thus the system couldn't find the binaries now located in /usr (and the RPM database couldn't be found because /var wasn't mounted).
Comment 2 David Lehman 2012-08-07 10:44:13 EDT
anaconda-16.25 is included in the F16 DVD -- not F17.

Please attach the logs from installation. They'll be in /var/log/anaconda/. Do not create an archive. Instead, attach the following log files one at a time as type text/plain:

 anaconda.storage.log
 anaconda.log
 anaconda.program.log
 anaconda.syslog

Thanks.
Comment 3 amylaar 2012-10-08 10:44:30 EDT
With Fedora 18 Alpha, the existing installations are displayed, but AFAICT
upgrade is impossible.
Comment 4 David Lehman 2013-05-30 12:41:06 EDT
(In reply to amylaar from comment #3)
> With Fedora 18 Alpha, the existing installations are displayed, but AFAICT
> upgrade is impossible.

Correct. Upgrade is now handled by fedup (the Fedora Upgrade Tool) as of Fedora 18.

Closing this report due to lack of response from the reporter.

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