root@vapier quake3-nsco # emerge -C quake3-osp app-games/quake3-osp selected: 1.03a protected: none omitted: none >>> Packages in red are slated for removal. >>> Packages in green will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging app-games/quake3-osp-1.03a... No package files given... Grabbing a set. <<< obj /usr/games/bin/quake3-osp <<< obj /usr/games/bin/q3ded-osp <<< obj /opt/quake3/osp/zz-osp-server3a.pk3 <<< obj /opt/quake3/osp/zz-osp-pak3.pk3 <<< obj /opt/quake3/osp/zz-osp-pak2.pk3 <<< obj /opt/quake3/osp/zz-osp-pak1.pk3 !!! Unable to copy file ' /opt/quake3/osp/zz-osp-pak0.pk3 '. !!! [Errno 28] No space left on device root@vapier tmp # emerge info Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1,2.3.2-r2) ================================================================= System uname: 2.4.21 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz GENTOO_MIRRORS=" http://192.168.0.3/gentoo " CONFIG_PROTECT="/etc /var/qmail/control /var/qmail/alias /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /opt/glftpd/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/X11/xkb /usr/X11R6/lib/X11/xkb /etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/root/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 dedicated nptl cdr scanner -3dfx -3dnow aalib -acl -afs -alsa apm -arts -atlas avi -berkdb -bonobo -canna -cjk crypt cups dga directfb -doc dvd encode esd -evo fbcon flash -freewnn -gb gd gdbm ggi -ggz gif -gnome -gnome-libs gphoto2 gpm gtk gtk2 -gtkhtml -guile -icc -icc-pgo imap imlib -innodb ipv6 java jpeg kde kerberos -lcms -ldap -libg++ -libgda libwww -matrox -maildir -mbox -mikmod mmx -motif mozilla mpeg -mule mysql nas ncurses -nls nocardbus -oci8 -odbc oggvorbis opengl -oss pam -pcmcia pda pdflib perl pic plotutils png pnp -postgres python qt qtmt quicktime readline -ruby samba sasl sdl -slang slp snmp socks5 spell sse ssl -static svga tcltk tcpd -tetex tiff truetype -trusted -voodoo3 wavelan X -xface xml xml2 xmms xv -zeo zlib" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O9 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" CXXFLAGS="-march=i686 -O9 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://192.168.0.3/gentoo-portage" FEATURES="sandbox ccache noauto"
still an issue ?
Err... why the hell was it copying?
(In reply to comment #2) > Err... why the hell was it copying? Only thing I can see is the prelink stuff trying to un-prelink files to get the correct on-disk md5sum. Since there is no space to copy the file to to un- prelink it things fail. From portage_exec: # Create non-prelinked temporary file to md5sum. # Raw data is returned on stdout, errors on stderr. # Non-prelinks are just returned. try: shutil.copy2(filename,prelink_tmpfile) except SystemExit, e: raise except Exception,e: portage_util.writemsg("!!! Unable to copy file '"+str(filename)+"'.\n") portage_util.writemsg("!!! "+str(e)+"\n") sys.exit(1)
Inside portage.dblink.unmerge() it does portage_checksum.perform_md5(obj, calc_prelink=1) which copies the file to a tempfile and runs "prelink --undo". This is inefficient because when prelink_capable==True, the copy is done for *every* obj file regardless of whether or not it is truly a prelinked binary.
(In reply to comment #4) > This is inefficient because when prelink_capable==True, the copy is done for > *every* obj file regardless of whether or not it is truly a prelinked binary. I have attached an optimization patch to bug 83379.
*** Bug 83379 has been marked as a duplicate of this bug. ***
*** Bug 67464 has been marked as a duplicate of this bug. ***
The patch attached to bug 83379 should mostly alleviate this problem because non-elf files are checksummed in place rather than copied.
*** Bug 9849 has been marked as a duplicate of this bug. ***
*** Bug 28578 has been marked as a duplicate of this bug. ***
*** Bug 29015 has been marked as a duplicate of this bug. ***
*** Bug 48395 has been marked as a duplicate of this bug. ***
*** Bug 52809 has been marked as a duplicate of this bug. ***
*** Bug 117590 has been marked as a duplicate of this bug. ***
*** Bug 137751 has been marked as a duplicate of this bug. ***
*** Bug 147147 has been marked as a duplicate of this bug. ***
*** Bug 156928 has been marked as a duplicate of this bug. ***
*** Bug 159718 has been marked as a duplicate of this bug. ***
*** Bug 149904 has been marked as a duplicate of this bug. ***
I assume this is fixed by now (the code in question doesn't exist anymore).
Reopening for duping.
Ehm, reopening yes, duping no
*** Bug 89306 has been marked as a duplicate of this bug. ***
*** Bug 96351 has been marked as a duplicate of this bug. ***
*** Bug 181821 has been marked as a duplicate of this bug. ***
*** Bug 190554 has been marked as a duplicate of this bug. ***
Could you please check if there's enough disk space for installation of the package before installing from /var/tmp to live system? I've just had a failed glibc merge because there was not enough space to copy all glibc files which made the machine unusable. This is the third time one of my machines ran out of disk space while installing glibc.
(In reply to comment #28) > Could you please check if there's enough disk space for installation of the > package before installing from /var/tmp to live system? Yes, it can be done with statvfs. However, the fact that separate partitions are often used for things like /usr and /var makes the calculation a bit tricky.
Ping, is this still a problem? This bug is not tracking anything; if it is meant to track the bug listed in the "See Also" field then please add it to "Depends on", thank you in advance.
