I have /tmp linked to /var/tmp in my existing installation. When anaconda creates /mnt/sysimage/foo if it is linked to /bar/feh in the real file system it also links it to /bar/feh when recreated in /mnt/sysimage. This causes anaconda to look for a file within the ramdisk instead of within the /mnt/sysimage/ directory. Which results in an unhandled exception. In the anaconda inspired installer I've been working on for Yellow Dog I use a chroot to avoid problems like this. Possible Solution: Boot old Linux install and remove symlink... then add it back after upgrade... possibly create the directory within the ramdisk from the installer shell... either way I dont think there is a good solution or workaround in the 7.0 installer. Good luck :) Best Regards, Charles Stevenson Software Engineer -- Terra Soft Solutions, Inc. http://www.terrasoftsolutions.com/ Yellow Dog Linux "The Ultimate Companion for a Dedicated Server" http://www.yellowdoglinux.com/ Black Lab Linux Workstations and advanced, Parallel Solutions http://www.blacklablinux.com/
Possible only a rare case if user has /tmp linked elsewhere...
It happened when anaconda tried to write /mnt/sysimage/tmp/upgrade.log since /mnt/sysimage/tmp -> /var/tmp
I noticed a similar issue #10308 which was closed (WONT) with the explanation that RPM cannot follow symlinks such as /home -> /usr/home... when in fact it is due to the means by which anaconda mounts the root filesystem within /mnt/sysimage. I dont have the source code handy but perhaps later I will try and submit a patch if time permits.
*** This bug has been marked as a duplicate of 13071 ***