Bug 830003

Summary:	Anaconda cannot upgrade F17 system with seperate /usr partition (/bin/arch has been move to /usr/bin/arch)
Product:	[Fedora] Fedora	Reporter:	Gaëtan Leurent <gaetan.leurent>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	17	CC:	anaconda-maint-list, collura, cyberrider, gaetan.leurent, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-23 17:53:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gaëtan Leurent 2012-06-08 01:11:05 UTC

Description of problem:

Anaconda cannot upgrate an F17 system with a seprate /usr partition.

It trys to run /bin/arch to detect the architecture of the installed system, but now that /bin has been merged with /usr/bin, there is no binary available if /usr is on a seperate partition.  Then it does not consider the installed system has upgradeable.  (I guess it was usefull to keep some binaries in the root partition, after all...)

In particular, if a F16->F17 upgrade (with a seprate /usr partition) is interrupted after the merge of /bin into /usr/bin, the result is a broken system that can't be upgraded :-(


Version-Release number of selected component (if applicable):

anaconda 17.29 (F17 installation DVD)

How reproducible:

Always.

Comment 1 Scott Marshall 2012-08-07 05:10:48 UTC

I have managed to successfully upgrade 3 different Fedora systems (14, 15 & 16) to Fedora 17, with /usr on a separate device, although in my case the separate device for /usr was actually a separate LV within the "root" volume group.

The major problem initially for me was that the anaconda installer was not scanning or finding my LVM setup.

I got around this by modifying the Install/Upgrade boot commands.
I appended the following options which solved my problem:
rd_LVM_LV=vg/rootlv rd_LVM_LV=vg/usrlv rd_LVM_LV=vg/varlv

By specifying these options, I successfully forced anaconda to scan, activate and mount the logical volumes in my volume group.  Of course, I used the exact names as they existed within my LVM, so anyone trying this will need to already know the name of the VG containing their root, usr and var LVs, along with the names of those LVs.

What should happen is that when anaconda is scanning the storage devices, it should automatically detect any and all volume groups (ie LVM2 members) and perform all necessary actions to activate the appropriate VGs and LVs.

If it needs any "hints", anaconda should trace the current boot actions.  ie Identify the boot/primary drive, identify the boot loader (or boot partition), then parse the grub or grub2 configuration for the current kernel loader (vmlinuz) options.  Those should identify any needed LVs by UUID or LVM path.

Comment 2 Scott Marshall 2012-08-07 06:20:56 UTC

I've raised my findings about the failure to scan LVMs in https://bugzilla.redhat.com/show_bug.cgi?id=846191

Comment 3 Chris Lumens 2012-10-23 17:53:25 UTC

We're moving to a new process for upgrading, which will not involve anaconda at all.  Thus, I think the original problem in this bug report will no longer be an issue and there's nothing for us to do in anaconda.  Thanks for the bug report.