Bugzilla Bug 79388

When I try to emerge anything (e.g., emerge -u portage), I get a failure to
make the work directory for the first dependent package being emerged (e.g.,
patch-2.5.9-r1)

The problem just appeared when I updated my profile as instructed.
Here are the steps I took to update (as instructed in response to previous
emerge --sync):
emerge -n '>=sysapps/portage-2.0.51'
cd /etc/
rm make.profile
ln -s ../usr/portage/profiles/default-linux/x86/2004.0 make.profile
emerge --sync

Another interesting fact about my system:
My first disk is on the full side, so I mounted a second disk and use symlinks
to put my portage on the second disk. (I've been running and emerging this way
for months.)
I have the second disk mounted as /mnt/portage and linked as follows:
/usr/portage => /mnt/portage/portage
/var/tmp/distfiles => /mnt/portage/tmp/distfiles
/var/tmp/portage => /mnt/portage/tmp/portage
/var/tmp/portage-pkg => /mnt/portage/tmp/portage-pkg


Reproducible: Always
Steps to Reproduce:
1. emerge -u portage


Actual Results:  
Calculating dependencies...
>>> emerge (1 of 34) sys-devel/patch-2.5.9-r1 to /
>>> md5...
ACCESS DENIED  mkdir: /mnt/portage/tmp/portage/patch-2.5.9-r1/work
install: cannot create directory '/var/tmp/portage/patch-2.5.9-r1/work':
permission denied

Note: I'm running as root. I also tried chown'ing the portage files to
portage:portage and such, which didn't help. If I manually create the
directory,
it still fails the same.

Expected Results:  
emerged dependencies (starting with patch);
emerged portage

worm:~# emerge info
Portage 2.0.51-r14 (default-linux/x86/2004.0, gcc-3.3.3, unavailable,
2.4.25-co-0.6.0 i686)
=================================================================
System uname: 2.4.25-co-0.6.0 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz
Gentoo Base System version 1.5.3
Python:               [2.3.4 (#1, Jan 20 2005, 16:10:04)]
dev-lang/python:     [Not Present]
sys-devel/autoconf:  [Not Present]
sys-devel/automake:  [Not Present]
sys-devel/binutils:  [Not Present]
sys-devel/libtool:   [Not Present]
virtual/os-headers:  [Not Present]
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=i586 -funroll-loops"
CHOST="i586-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=i586 -funroll-loops"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.ccccom.com
ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo
ftp://mirror.iawnet.sandia.gov/pub/gentoo/
http://open-systems.ufl.edu/mirrors/gentoo http://mirror.datapipe.net/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X bitmap-fonts f77 font-server fortran gif gtk gtk2 imlib ipv6 jpeg
libg++ libwww mad mpeg ncurses oggvorbis opengl pam perl png python qt readline
sdl slang spell ssl tcpd truetype truetype-fonts type1-fonts xml2 xmms xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY

Using mount --bind instead symlinks should solve this.

actually this is a sandbox issue (been covered in the past)

either use bind mounts as suggested or set the variables in your make.conf

Yup, mount --bind fixes (or masks) the problem. Thanks.