Summary: | sys-kernel/hardened-sources-3.5.4-r1 with CONFIG_PAX_RANDMMAP: system reboot while emerging glibc-2.15-r3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | manwe <gentoo> |
Component: | [OLD] Core system | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | hardened, kernel, lejonet |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://bpaste.net/show/55083/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
manwe
2012-11-03 17:15:39 UTC
Could you try with hardened-sources-3.5.4-r2? I had filesystem related problems with 3.5.4-r1 that was fixed with the -r1 and currently I am compiling glibc-2.15-r3 on that system, with CONFIG_PAX_RANDMMAP=y The paste seems to be cut-off at the last line too so important information might have been left out from that too. (In reply to comment #1) > Could you try with hardened-sources-3.5.4-r2? > > I had filesystem related problems with 3.5.4-r1 that was fixed with the -r1 > and currently I am compiling glibc-2.15-r3 on that system, with > CONFIG_PAX_RANDMMAP=y > > The paste seems to be cut-off at the last line too so important information > might have been left out from that too. With -r2 I mean, sorry for typo. Just to start some differential issue analysis, can you try with MAKEOPTS="-j1" ? Like I've said, I also tried newest hardened 3.6.4 with the same result, so if this was wixed in 3.5.4-r2 it also should work with 3.6.x, right? Log from emerging glibc isn't cut off, this is all I see before reboot. Every time. I'll try -j1 in hour or two. (In reply to comment #4) > Like I've said, I also tried newest hardened 3.6.4 with the same result, so > if this was wixed in 3.5.4-r2 it also should work with 3.6.x, right? > > Log from emerging glibc isn't cut off, this is all I see before reboot. > Every time. > > I'll try -j1 in hour or two. I emerged glibc-2.15-r3 on a 3.5.4-r2 kernel just now and worked without any hitch. Will be interesting to see if -j1 solved it for you, I have 2 6128 opteron and run -j16 and seeing as it's a HP Proliant server hardware issues can most likely be ruled out as you stated in the initial report. Have you tride older kernels? Could you give us the output of gcc-config -l, I can't find -fno-stack-protector in the CFLAGS part of your paste. It should be appended by the fully hardened compiler. I'm lost. I had few more files [for smaller packets] corrupted in /var/db/pkg [after first reboot] so I removed those folders, did emerge -1 for them and emerge -e world. Just to be sure, not sorry. And now, when I tried to recreate this reboot for you, I can't. Before I had no problem with it, happened all the time. Now the same config [http://bpaste.net/show/55081/] seems to be working fine. Event with -j6. Looks like we've lost it :/ # gcc-config -l [1] x86_64-pc-linux-gnu-4.5.4 * [2] x86_64-pc-linux-gnu-4.5.4-hardenednopie [3] x86_64-pc-linux-gnu-4.5.4-hardenednopiessp [4] x86_64-pc-linux-gnu-4.5.4-hardenednossp [5] x86_64-pc-linux-gnu-4.5.4-vanilla Well for your own sanity I suggest you do a memcheck and SMART check to rule out faulty hardware for reals. What filesystem you use? I did test both memory and cpu for at least few hours. RAID was checked by local people in server house, I don't have too much of a experience with those HP Arrays. Filesystem for / is [for now] ext3. I've tried mrproper/config/make one more time, and it's still working. No reboots. Problem was somewhere, but looks like it wasn't entirely kernel's fault, since emerge -e world fixed it. But I'll keep an eye on everything. Sorry for taking your time. No problem, good that you aren't seeing the issue anymore. Might have been a gremlin that was removed by the reboot or such. Ext3 shouldn't have issues with the recently found bug either, and that is also in newer kernels than you were using. |