Strange ebuild fails - not specific.

[Qcumber-some]

Hi,

on the two Gentoo machines I work with, I get strange Ebuild failed errors without a message. Mostly it happens within compilation, sometimes in postinstall, sometimes when unpacking. If I try to emerge the incriminated package again, it works.
I don't see any other misbehaviour on these machines.

One is a server:
Portage 2.1.4.5 (hardened/amd64, gcc-3.4.6, glibc-2.6.1-r0, 2.6.25-hardened-r9 x86_64)
System uname: 2.6.25-hardened-r9 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+

One is a laptop:
Portage 2.1.4.5 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r9 i686)
System uname: 2.6.25-gentoo-r9 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz

What can I do to find the source of this problem? If you need any more info, I'll happily provide.

Thanks.

[djinnZ]

On the hardened server, if you have the pax mprotect option active, can be process termination due to violation of protected areas (if so the paxtest will fail randomly, is a problem of the kernels from 2.6.20 release in my experience) but because the problem is present on a non hardened, 23 bit arch versurs a 64 bit, also is strange.

The other possibility is an hardware error caused by an elettrical incompatibilitu betwen the UPS, if present, and the power unit of the PC or an interference (the server of mine gone mad if use an old damaged CRT monitor by example) on the electical line or something as a reduction of the voltage supplied higer than 6% or a frequency oscillation higher than 10% (those values are only indicative for a 220V~50hz line, i dont know what is the limit on a 110V as used in north-america by example) but in this case you must have random errors of the compilers due to "internal or hardware bug" reported or you must experience memory corruption also.
Verify if you have one other electrical hi-power (more than 200W power request) device (old laser printers, crt monitors, boilers and so) connected to the same line of the pc or verify if the power unit of the server and of the laptop are not damaged and the output has costant voltage.

If the electrical line in your home/office is older than ten years is possible than you need to tighten the clamps of all the switchs and the sockets (the normal time for needing this operation is betwen 10 and 20 years for domestical lines supplied by 220V and max five for 380V, yearly for industrial use, as i remember).

Because my office is surrounded by construction sites (two new buildings and a new road authorized at the same time, i pray every day for a slow horrible death of the mayor of my city and his henchmans ) I have a similar problem and have reported. By exaple my laptop hangs often at compile time but only at work never at home.
But at work I see often the lights become darker for fractions of seconds.

I have no more suggestions. Sure if is an electrical problem is very hard to find and solve.

[OT]The question seems more related to the kernel/hardware section. Ask to the moderators or report[/OT]
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[richard.scott]

I had a problem like that and it ended up being a hardware issue.

I ran the memtest that comes on the Gentoo LiveCD and it failed on my dimms.
However, the motherboard died shortly after too!

[Qcumber-some]

Sorry I couldn't reply earlier.

I don't suspect hardware failure due to the fact that it happens on two completely different machines which are located in two completely different settings, separated by some 100km of Germany
Maybe it's a kernel thing, but on the other hand I configured other kernels in a similar matter and they don't show the symptoms. However I don't have other Gentoo machines at the very same locations.

From the time writing, it didn't happen anymore. Maybe it was a temporary glitch, but it happened several times over several days, so I thought it could be a systematic problem.

I think I'll close this topic - even if it happens again, it's too vague to find a solution if I can't provide any more useful information.

Thanks to both of you.

[djinnZ]

I repeat the suggestion to try a sequence of more than one paxtest and see if it die without reasons but because the problem is present on a non-hardened too I have a supspicion of a python issue or from a ccache corrupted (and the results are ever damaged, but if you have not experienced crashes at compile time you can exclude).

Sure than you have not missed some rebuilding at time of the python update?
Remove the cruft from i486 path (i have found in some stage3 archives) and outdated python modules if there are.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist