Bug 830003 - Anaconda cannot upgrade F17 system with seperate /usr partition (/bin/arch has been move to /usr/bin/arch)
Anaconda cannot upgrade F17 system with seperate /usr partition (/bin/arch ha...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 21:11 EDT by Gaëtan Leurent
Modified: 2012-10-23 13:53 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-23 13:53:25 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 Gaëtan Leurent 2012-06-07 21:11:05 EDT
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 01:10:48 EDT
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 02:20:56 EDT
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 13:53:25 EDT
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.

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