From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030529 Description of problem: Install complains and fails hard when /usr/tmp is not a symbolic link to ../var/tmp. It is not inconcieveable that the local admin has reasons to use a real /usr/tmp directory, the install should not fail if it isn't the desired symbolic link. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. cd /usr 2. rm tmp 3. mkdir tmp 4. chmod 777 tmp; chmod +t tmp Actual Results: Install process complains about non-symlink and halt install Expected Results: no error should be found Additional info:
I get the same error when attempting to upgrade a 7.3 system to 9.0. But my /usr/tmp IS a link to ../var/tmp. Are there other permissions on /usr/tmp that may be causing the failure?
#1: We do not support having /usr/tmp in any other fashion. #2: What does ls -l say for /usr/tmp?
% ls -l /usr/tmp lrwxrwxrwx 1 root root 10 May 13 2002 /usr/tmp -> ../var/tmp I suppose I'll just remove the symlink if I try and upgrading again.
If you want to experiment try this: > python import os print os.readlink("/usr/tmp") <cntl-d> and let me know what it prints out. This won't hurt any data. This is the check we do in anaconda. On my system it prints "../var/tmp"
% python Python 1.5.2 (#1, Jan 31 2003, 10:58:35) [GCC 2.96 20000731 (Red Hat Linux 7.3 2 on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> print os.readlink("/usr/tmp") ../var/tmp %
Well, in re: #1 There are reasons that the local admin might want to have the /usr/tmp as a real directory. It *should* be supported. In re #2, I fixed the link and got the install to work.
Unfortunately because of the way upgrades/rpm work we can't change this behavior, as it would basically break upgrades. The filesystem package expects this to be a symlink.