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.
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.
I've raised my findings about the failure to scan LVMs in https://bugzilla.redhat.com/show_bug.cgi?id=846191
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.