FC17 x86_64 install DVD doesn't recognise existing FC16 following /usr-move failure

[AndyW]

I am trying to upgrade from FC16 to F17 using the x86_64 DVD. CPU is AMD FX-6100, M/b Gigabyte GA-970A-DS3.

First time round /usr-move failed due to lack of free space on /usr, which is on a separate partition to /. Now when I re-run the install it fails to recognise the existing FC16 installation. Both the FC16 and FC17 Live CDs can recognise it and boot from HDD, and the FC16 install DVD also recognises it.

Following the failure of /usr-move I had to edit grub.cfg, as it had managed to get as far as moving /sbin/init to /usr. I posted that saga here http://forums.fedoraforum.org/showthread.php?t=280880 but have started a new thread is it appears to be a different issue now. The system boots to FC16 without problem. There is no dual-boot, disk encryption or anything else odd - apart from the fact that there are separate partitions for /, /usr, /var and /usr/local. However this has never caused a problem with previous upgrades, and the FC17 upgrade started off OK first time round.

The only material differences from first time are the necessary changes to grub.cfg to get the system to boot, and the changed space utilisation in / and /usr. I am aware I still need to resize /usr, but if the installer is checking that I would expect an error message of some kind rather than for it to completely ignore the existing installation. Is there anything else the FC17 installer might check for?

NB: The symptoms are similar to #748119 on FC16 https://bugzilla.redhat.com/show_bug.cgi?id=748119 due to /var being on a separate partition to /, though the workaround for that is still in place on the system.

[AndyW]

UPDATE: I re-sized partitions to add free space on /usr, and completed the /usr-move separately using Dracut, following the procedure here:- http://fedoraproject.org/wiki/Upgrad...-.3E_Fedora_17 - it looks like /usr-move had pretty much finished anyway when it ran first time from the Anaconda installer.

Still no luck...could it be that Anaconda will only recognise an installation that hasn't had /usr-move applied - in which case will changing the new symlinks back into real directories (albeit empty ones) fool it back into action?

[AndyW]

Reported as bug #835307 https://bugzilla.redhat.com/show_bug.cgi?id=835307.

Also attached /tmp/anaconda.log, /tmp/storage.log and /tmp/program.log from a typical upgrade attempt. Maybe someone can advise what to look for in those?

[AndyW]

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.

I tried adding

inst.upgradeany

to the kernel boot parameters line (not sure where else I could put this?) which is supposed to skip these checks, but makes no difference - I still get the same error line.

So I guess my question now is, is it impossible to upgrade to upgrade to FC17 if both (a) /usr-move has completed and (b) /usr is on a separate partition?

Andrew

[jlpierce]

Originally Posted by AndyW

So I guess my question now is, is it impossible to upgrade to upgrade to FC17 if both (a) /usr-move has completed and (b) /usr is on a separate partition?

Andrew

I cannot attest to the /usr-move part, but I can attest to the /usr separate partition aspect. I traditionally had /usr on a separate partition and I had to delete it and merge the space into the / partition before a clean install would work.

Based on that, I would speculate that an upgrade would fail under that condition as well. According to what I read it is necessary for /usr to be on the / when mounted to proceed with proper boot operations.

YMMV here though.

[AndyW]

After /usr-move did its stuff I had to edit the kernel boot parameters so it could "see" the /usr partition. However the background info on /usr-move says that it facilitates having a separate /usr, which I can appreciate. While I wouldn't put /usr on a separate partition if doing it again, I don't seee anything saying it absolutely can't be done.

As it is possible to carry out /usr-move independently using dracut it is far from impossible that someone could be upgrading 16 -> 17 on a /usr-moved system.