Red Hat Bugzilla – Bug 835307
FC17 x86_64 install DVD doesn't recognise existing FC16 following /usr-move failure
Last modified: 2013-01-10 01:50:33 EST
Created attachment 594307 [details]
Description of problem:
Trying to upgrade from FC16 to F17 using the x86_64 DVD. I have separate partitions for /, /var, /usr and /usr/local.
First time round Anaconda recognised existing FC16 and started /usr-move, which failed due to lack of free space on /usr; however /usr-move seemed to have completed and had created all new symlinks. Resized partitions so all have adequate free space and ran /usr-move independently using dracut following procedure here: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17. I had to edit grub.cfg to make /usr visible during to bootloader, but otherwise no problem booting to FC16; see FedoraForum post here: http://forums.fedoraforum.org/showthread.php?t=281463
Now when I re-run the install DVD it fails to recognise the existing FC16 installation. If I go to Rescue Mode it says "You don't have any Linux partitions". Both the FC16 and FC17 Live CDs can recognise it and boot from HDD, and the FC16 install DVD also recognises it.
Symptoms look same as FC16 installer bug #748119 but workaround there (copy contents of /var/lib/rpm to copy of that directory in / filesystem) doesn't work here.
Version-Release number of selected component (if applicable):
FC17 x86_64 install DVD
Boot from DVD and select Install / Upgrade
Steps to Reproduce:
Anaconda treats storage as if currently unused.
Recognise existing FC16 installation and give option to upgrade
Created attachment 594308 [details]
Created attachment 594309 [details]
Created attachment 594310 [details]
I noticed that anaconda.log has the following lines for FC17 upgrade but not for FC16
22:04:48,984 DEBUG anaconda: isys.py:mount()- going to mount /dev/mapper/VolGroup00-LogVol00 on /mnt/sysimage as ext3 with options ro
22:04:49,026 ERR anaconda: Error running arch: No such file or directory
22:04:49,035 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage, removeDir = False
It looks like this suggestion (https://bugzilla.redhat.com/show_bug.cgi?id=748119#c51) to use /bin/arch to determine system architecture (instead of examining RPM database) has been implemented in Anaconda.
Of course, as /usr-move has completed so /bin is now a symlink to /usr/bin, and as /usr is on a separate partition, Anaconda can't find arch when just / is mounted.... I have tried both replacing the symlink with a real directory containing a copy of arch, and creating a real bin directory (also containing a copy of arch) under the /usr mountpoint - both without success, as anaconda.log contains the same error message. This could be because other dependencies are missing, even though /bin/arch is accessible.
So is it impossible to upgrade to upgrade to FC17 if both (a) /usr-move has completed and (b) /usr is on a separate partition?
I think you have managed to get your system into a state anaconda cannot deal with. Certainly not an expected state. At this point it may be better to attempt the upgrade with yum directly as you'll have more control over the environment.
Unfortunately I don't think there is anything anaconda can do with this.