Somehow gzip sometimes do not work from ebuild.sh manually doing the same command (line 24 of unpack) works flawlessly and both regards all packages with distfiles/*tar.gz (tar included) palpable is running gentoo-1.4_beta on gcc-3.2-r1 I've also had the same problem on another system running the default-1.0 profile (gentoo-1.2) Somehow the problem disappeared on the other box, nevertheless I cannot recall doing anything there that should explain the "recovery" to a healty state. <snip> [palpable] root:/usr/portage.local# emerge evms Calculating dependencies ...done! >>> emerge sys-apps/evms-1.1.0 to / >>> md5 ;-) evms-1.1.0.tar.gz >>> Unpacking source... >>> Unpacking evms-1.1.0.tar.gz /usr/sbin/ebuild.sh: line 24: 3821 Segmentation fault tar xz --no-same-owner -f ${DISTDIR}/${x} !!! ERROR: The ebuild did not complete successfully. !!! Function unpack, Line 24, Exitcode 139 !!! failure unpacking evms-1.1.0.tar.gz </snip>
and .. well .. both (at least palpable) runs on portage-2.0.36
with what version of portage did this occur ?
Seems like I have managed to find what indirectly is causing this; I am using nss-mysql and when my nsswitch.conf reads passwd: files mysql shadow: files mysql group: files mysql emerge seems to break changeing to passwd: files shadow: files group: files before using emerge makes everything work. From this I get that: 1) either portage or nss-mysql has a serious bug 2) if it is a portage problem it might have something to do with sandbox, or maybe something else; is there something doing checks for valid users/userids? 3) Something worth to investigate: will using nscd aviod this behavior? I'll put further investigation into the matter as soon as I've got time Christian
Running nscd does aswell cancel the problem. Somehow something times out(?) when doing it the slow way (mysql), so nscd is a good idea when running nss-mysql Christian
I'm a little under the knownledge of what exactly this does. I get the idea from the bug report. Do you have a solution to this that you can incorportate into the ebuild you submitted for nss-mysql? I can't test this or fix it. Can you?
Created attachment 4139 [details] nss-mysql.0.43.tar.bz2
I don't think it is wise to enable nscd for the user. She/he should do it him/herself, have added an advisory suggesting to enable nscd that shows up when emerging / doing the ebuild nss- mysql.0.43.ebuild config. nscd (name service cache daemon) is a part of glibc and caches information (probably all information going through nss - see /etc/nsswitch) Christian
I ran acress this problem as well, and even with .43 it happens, but it is a problem with tar its self and not the decompessor (I verified this by modifying the ebuild.sh to break apart decomp and tar.) when I first ran an strace it seemed to crash after tryign to load libnss_db (which I do not have.) but it seems that the problem stems form somehow doing a gentent agains mysql while tar is running. If anyone knows the commands I can run an strace against a simple ebuild and provide them to hopefully solve this problem.
I have gotten the system to work properly after re-emerging binutils. The problem is related to the version of GLIBC your initial bootkit was linked against. A change in GLIBC 3.2 broke the NSS library.
So is this still a problem and has it to do with portage itself?
this is not a portage problem, it's a problem with nss-mysql. i've seen it with nss-ldap as well.
closing as per comment #9.
I'm having the same issues, and re-emerging binutils (or glibc) didn't do the trick. I also tried to use nscd, didn't work either.
matje: recompile your nss modules.
My apoligies, apparently nscd does work, it didn't run properly over here, now it does. For as far as I can tell, the bug is located in nss-mysql, I think it returns control too soon without returning the requested info. Nscd seems to catch this error. I have found another solution: adding --numeric-owner to $tarvars in ebuild.sh, this makes tar not ask the info it wants (about the username of the developer), which you don't need anyway. I find it strange that untarring it manually does work though, no errors then. I'll post another bug for the portage developers so they can change this as they seem fit.
Recompiling the nss-modules didn't work