On Tue, Jul 15, 2014 at 02:40:13AM -0500, Dale wrote: > Hinnerk van Bruinehsen wrote: > > I've taken a look at the bug that is mentioned in the error and there were > > several things mentioned that are supposed to fix this: > > > > 1. disable auditd (if you have it running) - this was the newest (from > > '14) > > So if you have it installed run /etc/init.d/auditd stop > > 2. reemerge several packages because python may have issues: > > - sync your tree > > - emerge portage (which will likely pull in some python stuff if the > > box > > wasn't updated for some time) > > (- optional: run eselect python and select a sane version and run > > python > > updater - this wasn't mentioned but may make sense nonetheless) > > - emerge linux-headers > > - emerge glibc (hopefully with success this time) > > > > WKR > > Hinnerk > > I didn't have the audit stuff installed BUT it was turned on in the > kernel. I kicked that out and also got rid of all that cgroup stuff I > don't have any need for. Rebooted then tried your list. Audit stuff, > gone. Sync is maybe a couple days old so should be OK. Portage is up to > date. Python as follows: > > dev-lang/python-2.7.6 > dev-lang/python-3.3.3 > > localhost ~ # eselect python list > Available Python interpreters: > [1] python2.7 * > [2] python3.3 > localhost ~ # > > Updated linux-headers. It was a little out of sync with kernel > version. After all that, I get this: > <SNIP> > > So, the locale junk is gone but glibc is still not liking something. > Where did I put that hammer the last time I used it?? ;-) > > Ideas? I'm pretty much out of them right now. My idea is the hammer. > lol
Generally hammers tend to make things worse... ;-)
Can you run;
printf "#include <unistd.h>\n#include <sys/syscall.h>\nint main(){return \
syscall(1000)!=-1;}\n" > syscall.c && make syscall && ./syscall && echo $?
(It should be all one line).
It will compile the test that seems to fail on your system and runs it,
expected output would be:
cc syscall.c -o syscall
0
The "0" says that all went well, if it reports something else then it's not
just the buildsystem...
If it's the system you'll have to reinstall glibc (no kidding, as it provides
the used headers (though they should be somewhat dependent on linux-headers)).
You could do the following to break out of this chicken-and-egg-problem:
you can download an appropriate stage3-tarball (x86 or amd64) and extract it to
some arbitrary location. Then you essentially do the same as if you would
install gentoo from scratch (bind mount dev and sys and mount proc) and chroot
into it.
Inside the chroot you sync your tree (you could also bind-mount it from the
default location) and emerge glibc again but this time with the --build-pkg
flag set (emerge --buildpkg glibc). As long as you kernel is new enough (which
3.15.5 definitely is) the build should succeed and leave you with a nice binpkg
of glibc sitting in <path-to-chroot>/usr/portage/packages (in case of the
bind mount it should also be there inside your real system). If needed copy
it to /usr/portage/packages and run emerge -K glibc (this will force portage
to use the binpkg).
I hope that this es enough to circumvent the check (if not you could also try
to boot your rig from usb and copy the contents of the binpkg manually).
If the build breaks even inside the chroot run uname -a and take a look if the
kernel you're running acutally reports to be a 3.15.5 one.
Good luck,
Hinnerk
signature.asc
Description: Digital signature
