If PORTAGE_TMPDIR is set to a value other than /var/tmp... then the emerge of coreutils-5.0 will fail... it was my understanding that this was supposed to be fixed in portage-2.0.48-r5... however this is not the case... if PORTAGE_TMPDIR=/var/tmp... then coreutils-5.0 emerges without problems.. Reproducible: Always Steps to Reproduce: 1.set PORTAGE_TMPDIR to something other than /var/tmp 2.emerge coreutils 3. Actual Results: make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/os2/portage-tmp/portage/coreutils-5.0/work/coreutils-5.0' make[1]: Leaving directory `/os2/portage-tmp/portage/coreutils-5.0/work/coreutils-5.0' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-coreutils-5.0-27070.log" unlink: /portage-tmp/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/c And so on... Expected Results: Emerge should work successfully..
It works fine here. Please try the following: -------------------- nosferatu sandbox $ cat test.c #include <stdlib.h> #include <sys/param.h> #ifdef PATH_MAX # define SB_PATH_MAX PATH_MAX * 2 # if (SB_PATH_MAX >= INT_MAX) || (SB_PATH_MAX < PATH_MAX) # undef SB_PATH_MAX # define SB_PATH_MAX PATH_MAX + 25 # if (SB_PATH_MAX >= INT_MAX) || (SB_PATH_MAX < PATH_MAX) # error SB_PATH_MAX too big! # endif # endif #else # error PATH_MAX not defined! #endif int main() { printf("Value of INT_MAX is %i\n", INT_MAX); printf("Value of PATH_MAX is %i\n", PATH_MAX); printf("Value of SB_PATH_MAX is %i\n", SB_PATH_MAX); return 0; } nosferatu sandbox $ gcc -o test test.c nosferatu sandbox $ ./test Value of INT_MAX is 2147483647 Value of PATH_MAX is 4096 Value of SB_PATH_MAX is 8192 nosferatu sandbox $
I got the same results as you did: Value of INT_MAX is 2147483647 Value of PATH_MAX is 4096 Value of SB_PATH_MAX is 8192 Okay... the problem is this: I did some testing... and it seems i will only get this failure when PORTAGE_TMPDIR resides on a different physical hard disk... i tested using two partitions... and setting PORTAGE_TMPDIR to /os/tmp... and /os2/tmp... both these directories are owned by root... both have permission 1777 set on the directory... both use the same file system (XFS)... yet they reside on different physical disks... the one that works... /os/tmp resides on the same physical disk as /var/tmp... while /os2/tmp resides on a different physical hard disk... i hope you can replicate this error... if you have access to a 2nd physical disk you can test this with.. I wasn't the only one with this problem... follow this link on the gentoo forums: http://forums.gentoo.org/viewtopic.php?p=423018
I can confirm this bug, even tried replacing every reference to /var/tmp in sandbox.c with the other dir, still happens. Quick grep for /var on the portage code also didn't reveal anything. The test program also works here.
I have it on a different hdd, although its ext3: ------------------------------------------- nosferatu root # mount /dev/hde3 on / type ext3 (rw,noatime) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev type devfs (rw) none on /dev/pts type devpts (rw) /dev/hde4 on /home type ext3 (rw,noatime) /dev/hdc1 on /space type ext3 (rw,noatime) none on /dev/shm type tmpfs (rw) none on /proc/bus/usb type usbfs (rw) nosferatu root # ls -ld /var/tmp/portage lrwxr-xr-x 1 root root 27 Feb 26 06:46 /var/tmp/portage -> ../../space/var/tmp/portage nosferatu root # ls -ld /var drwxr-xr-x 14 root root 4096 Jul 22 22:59 /var nosferatu root # ls -ld /var/tmp drwxrwxrwt 2 root root 4096 Jul 24 19:03 /var/tmp nosferatu root #
I forgot to mention that in my tests it also failed when PORTAGE_TMPDIR is on the same filesystem / partition as /var/tmp and it was not a symlink. The command I used was "PORTAGE_TMPDIR=/test imerge -B \>=coreutils-5" and /test is just another directory on my / partition (as is /var/tmp/portage, I only have a big / partition on this box). However, I just it on my laptop (running 2.6-mm2), it works there. Could it be kernel related ?
Okay i really don't understand this... I emerged the latest portage-2.0.48-r7... and it's still causing problems... this time with a directory on another physical disk... and the directory on the other physical disk i was having problems with... well coreutils-5.0 is emerging fine now with PORTAGE_TMPDIR set to that directory... make sense ? Anyways... if i try to make other PORTAGE_TMPDIR's... in the same root directory as the PORTAGE_TMPDIR that works... the ebuild fails... it doesn't make sense heh.. Well i hope u understand all that... in any case... these errors are really hard to track down.. Pat.
Created attachment 15149 [details] sandbox-1.1.tar.bz2 This is prob the same issue still as bug #21766. Please try this version of sandbox. You can simply do to install (note that you should not remerge portage after) as root: # tar -jxf sandbox-1.1.tar.bz2 # cd sandbox-1.1 # make all install
*** This bug has been marked as a duplicate of 21766 ***
