1 |
On Tue, Jul 15, 2014 at 02:40:13AM -0500, Dale wrote: |
2 |
> Hinnerk van Bruinehsen wrote: |
3 |
> > I've taken a look at the bug that is mentioned in the error and there were |
4 |
> > several things mentioned that are supposed to fix this: |
5 |
> > |
6 |
> > 1. disable auditd (if you have it running) - this was the newest (from '14) |
7 |
> > So if you have it installed run /etc/init.d/auditd stop |
8 |
> > 2. reemerge several packages because python may have issues: |
9 |
> > - sync your tree |
10 |
> > - emerge portage (which will likely pull in some python stuff if the box |
11 |
> > wasn't updated for some time) |
12 |
> > (- optional: run eselect python and select a sane version and run python |
13 |
> > updater - this wasn't mentioned but may make sense nonetheless) |
14 |
> > - emerge linux-headers |
15 |
> > - emerge glibc (hopefully with success this time) |
16 |
> > |
17 |
> > WKR |
18 |
> > Hinnerk |
19 |
> |
20 |
> I didn't have the audit stuff installed BUT it was turned on in the |
21 |
> kernel. I kicked that out and also got rid of all that cgroup stuff I |
22 |
> don't have any need for. Rebooted then tried your list. Audit stuff, |
23 |
> gone. Sync is maybe a couple days old so should be OK. Portage is up to |
24 |
> date. Python as follows: |
25 |
> |
26 |
> dev-lang/python-2.7.6 |
27 |
> dev-lang/python-3.3.3 |
28 |
> |
29 |
> localhost ~ # eselect python list |
30 |
> Available Python interpreters: |
31 |
> [1] python2.7 * |
32 |
> [2] python3.3 |
33 |
> localhost ~ # |
34 |
> |
35 |
> Updated linux-headers. It was a little out of sync with kernel |
36 |
> version. After all that, I get this: |
37 |
> |
38 |
<SNIP> |
39 |
> |
40 |
> So, the locale junk is gone but glibc is still not liking something. |
41 |
> Where did I put that hammer the last time I used it?? ;-) |
42 |
> |
43 |
> Ideas? I'm pretty much out of them right now. My idea is the hammer. |
44 |
> lol |
45 |
|
46 |
Generally hammers tend to make things worse... ;-) |
47 |
|
48 |
Can you run; |
49 |
|
50 |
printf "#include <unistd.h>\n#include <sys/syscall.h>\nint main(){return \ |
51 |
syscall(1000)!=-1;}\n" > syscall.c && make syscall && ./syscall && echo $? |
52 |
|
53 |
(It should be all one line). |
54 |
It will compile the test that seems to fail on your system and runs it, |
55 |
expected output would be: |
56 |
|
57 |
cc syscall.c -o syscall |
58 |
0 |
59 |
|
60 |
The "0" says that all went well, if it reports something else then it's not |
61 |
just the buildsystem... |
62 |
|
63 |
If it's the system you'll have to reinstall glibc (no kidding, as it provides |
64 |
the used headers (though they should be somewhat dependent on linux-headers)). |
65 |
|
66 |
You could do the following to break out of this chicken-and-egg-problem: |
67 |
you can download an appropriate stage3-tarball (x86 or amd64) and extract it to |
68 |
some arbitrary location. Then you essentially do the same as if you would |
69 |
install gentoo from scratch (bind mount dev and sys and mount proc) and chroot |
70 |
into it. |
71 |
Inside the chroot you sync your tree (you could also bind-mount it from the |
72 |
default location) and emerge glibc again but this time with the --build-pkg |
73 |
flag set (emerge --buildpkg glibc). As long as you kernel is new enough (which |
74 |
3.15.5 definitely is) the build should succeed and leave you with a nice binpkg |
75 |
of glibc sitting in <path-to-chroot>/usr/portage/packages (in case of the |
76 |
bind mount it should also be there inside your real system). If needed copy |
77 |
it to /usr/portage/packages and run emerge -K glibc (this will force portage |
78 |
to use the binpkg). |
79 |
|
80 |
I hope that this es enough to circumvent the check (if not you could also try |
81 |
to boot your rig from usb and copy the contents of the binpkg manually). |
82 |
|
83 |
If the build breaks even inside the chroot run uname -a and take a look if the |
84 |
kernel you're running acutally reports to be a 3.15.5 one. |
85 |
|
86 |
Good luck, |
87 |
Hinnerk |