Re: [gentoo-user] Re: updating old box: segfaults with python
Am 17.01.2014 18:14, schrieb Daniel Frey:
> On 01/16/2014 08:07 PM, lovely2 wrote:
>> I doubt this is a memory problem. I've just had the same problem with
>> glibc-2.17 and python. I manually went back to glibc-2.16 and everything is
>> fine again. I then tried re-emerging all the python versions with glibc-2.16
>> installed and then re-emerged glibc-2.17 and had the same problem.
>>
>> After running strace on the python2.7. My best guess is that it is a kernel
>> <> glibc-2.17 incompatiblity. The segfault happens near a mprotect
>> operation, very early on.
>>
>> vault ~ # strace python
>> -- snip --
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>> 0xb7462000
>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb74626c0, limit:1048575,
>> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
>> seg_not_present:0, useable:1}) = 0
>> mprotect(0xb7658000, 8192, PROT_READ) = 0
>> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>> +++ killed by SIGSEGV +++
>> Segmentation fault
>>
>> vault ~ # uname -a
>> Linux vault 2.6.31-gentoo-r10 #1 SMP Sun Mar 7 14:35:15 EST 2010 i686
>> Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux
>>
>> I'm upgrading to the latest gentoo-sources. Only thing i'm worried about is
>> rebooting but all in the life of a gentoo user.
>
> That could very well be (kernel issue with glibc-2.17.) I just upgraded
> some 3 year old gentoo VMs and managed to get everything installed. The
> kernel was the last thing I did have to upgrade, but I was on
> gentoo-sources-2.6.32 and had no segfault problems.
>
> From memory, I had to upgrade things in this order:
> -run emerge --sync
> -gcc (then switch to new version)
> -emerge libtool, binutils, linux-headers, glibc (glib as a dependency
> had to be masked to build, may have to solve some other blocks like a
> fallocate64 error, i think i had to use `ac_cv_func_fallocate=no emerge
> bintuils` so libtool would build?)
> -rebuild gcc (advise from the gcc package - rebuild after glibc update)
> -upgrade baselayout and openrc (inc. udev, module-init-tool->kmod, etc)
> -perl (then run perl-cleaner)
> -python (then remove all stale versions of 3.x and 2.x, switch active to
> 2.7)
> -python-updater
> -upgrade portage, portage-utils
> -unmask things I'd individually masked and try to solve blocks emerging
> world
> -eventually world would run, make sure everything built
> -run emerge-pvuDNe to make sure nothing was missed (something always is)
> then upgrade those packages
> -run emerge --depclean
> -run emerge @preserved-rebuild
> -run python-update & perl-cleaner
> -run revdep-rebuild
> -build & install new kernel (in my case 3.10.25)
> -reboot
>
> Damn, it works and it's up to date. Now I wish I could say that only
> took an hour, but on the first machine it took me almost 10 hours
> because I was almost always trying to work around blocks. The very last
> one I got down to 7 hours as I knew exactly what I had to do.
Thanks for your feedback!
I will check back here ... in the next week I will have another old box
to update, this time from a kernel 2.6.27-gentoo-r8 ... with gcc 4.1.2,
and udev 124-r2 !!
It was kept in this state to keep good old vmware-player-1.x running.
Now I deployed a new gentoo-based KVM-server there ... at last!
Stefan
[gentoo-user] Re: updating old box: segfaults with python [Solved] for me at least.
And bingo was his nameo. Updated kernel to 3.6.25 and emerge glibc-2.17 and python still works. :) -- View this message in context: http://gentoo.2317880.n4.nabble.com/updating-old-box-segfaults-with-python-tp274112p274876.html Sent from the gentoo-user mailing list archive at Nabble.com.
Re: [gentoo-user] Re: updating old box: segfaults with python
On 01/16/2014 08:07 PM, lovely2 wrote:
> I doubt this is a memory problem. I've just had the same problem with
> glibc-2.17 and python. I manually went back to glibc-2.16 and everything is
> fine again. I then tried re-emerging all the python versions with glibc-2.16
> installed and then re-emerged glibc-2.17 and had the same problem.
>
> After running strace on the python2.7. My best guess is that it is a kernel
> <> glibc-2.17 incompatiblity. The segfault happens near a mprotect
> operation, very early on.
>
> vault ~ # strace python
> -- snip --
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb7462000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb74626c0, limit:1048575,
> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0
> mprotect(0xb7658000, 8192, PROT_READ) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> Segmentation fault
>
> vault ~ # uname -a
> Linux vault 2.6.31-gentoo-r10 #1 SMP Sun Mar 7 14:35:15 EST 2010 i686
> Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux
>
> I'm upgrading to the latest gentoo-sources. Only thing i'm worried about is
> rebooting but all in the life of a gentoo user.
That could very well be (kernel issue with glibc-2.17.) I just upgraded
some 3 year old gentoo VMs and managed to get everything installed. The
kernel was the last thing I did have to upgrade, but I was on
gentoo-sources-2.6.32 and had no segfault problems.
>From memory, I had to upgrade things in this order:
-run emerge --sync
-gcc (then switch to new version)
-emerge libtool, binutils, linux-headers, glibc (glib as a dependency
had to be masked to build, may have to solve some other blocks like a
fallocate64 error, i think i had to use `ac_cv_func_fallocate=no emerge
bintuils` so libtool would build?)
-rebuild gcc (advise from the gcc package - rebuild after glibc update)
-upgrade baselayout and openrc (inc. udev, module-init-tool->kmod, etc)
-perl (then run perl-cleaner)
-python (then remove all stale versions of 3.x and 2.x, switch active to
2.7)
-python-updater
-upgrade portage, portage-utils
-unmask things I'd individually masked and try to solve blocks emerging
world
-eventually world would run, make sure everything built
-run emerge-pvuDNe to make sure nothing was missed (something always is)
then upgrade those packages
-run emerge --depclean
-run emerge @preserved-rebuild
-run python-update & perl-cleaner
-run revdep-rebuild
-build & install new kernel (in my case 3.10.25)
-reboot
Damn, it works and it's up to date. Now I wish I could say that only
took an hour, but on the first machine it took me almost 10 hours
because I was almost always trying to work around blocks. The very last
one I got down to 7 hours as I knew exactly what I had to do.
The problem is it doesn't look like there's still an old 2.6 kernel in
the tree you can upgrade to so it might be difficult:
$ eshowkw gentoo-sources
Keywords for sys-kernel/gentoo-sources:
| | u |
| a a a p s | n |
| l m r h i m m p s p | u s | r
| p d a m p a 6 i p c 3 a x | s l | e
| h 6 r 6 p 6 8 p p 6 9 s r 8 | e o | p
| a 4 m 4 a 4 k s c 4 0 h c 6 | d t | o
--+-+-+---
3.0.101| ~ ~ ~ o ~ ~ o o ~ ~ ~ ~ ~ ~ | o 3.0.101 | gentoo
--+-+-+---
3.2.54| ~ ~ ~ o ~ ~ o o ~ ~ ~ ~ ~ ~ | o 3.2.54| gentoo
--+-+-+---
3.4.76| ~ ~ ~ o ~ ~ o o ~ ~ ~ ~ ~ ~ | o 3.4.76| gentoo
--+-+-+---
3.4.77| ~ ~ ~ o ~ ~ o o ~ ~ ~ ~ ~ ~ | o 3.4.77| gentoo
--+-+-+---
3.4.| o o o o o o o o o o o o o o | o 3.4. | gentoo
--+-+-+---
3.9.11-r1 | o ~ ~ o o ~ o o o o o o o ~ | o 3.9.11-r1 | gentoo
--+-+-+---
3.10.7| + + + o + + o ~ + + + + + + | o 3.10.7| gentoo
--+-+-+---
3.10.7-r1 | + + + o + + o ~ + + + + + + | o 3.10.7-r1 | gentoo
--+-+-+---
[I]3.10.17| ~ + ~ o + ~ o ~ ~ ~ ~ ~ ~ + | o 3.10.17 | gentoo
--+-+-+---
3.10.25| ~ + + o + + o ~ + + ~ ~ ~ + | o 3.10.25 | gentoo
--+-+-+---
3.10.26| ~ ~ ~ o ~ ~ o ~ ~ ~ ~ ~ ~ ~ | o 3.10.26 | gentoo
--+-+-+---
3.10.27| ~ ~ ~ o ~ ~ o ~ ~ ~ ~ ~ ~ ~ | o 3.
[gentoo-user] Re: updating old box: segfaults with python
I doubt this is a memory problem. I've just had the same problem with
glibc-2.17 and python. I manually went back to glibc-2.16 and everything is
fine again. I then tried re-emerging all the python versions with glibc-2.16
installed and then re-emerged glibc-2.17 and had the same problem.
After running strace on the python2.7. My best guess is that it is a kernel
<> glibc-2.17 incompatiblity. The segfault happens near a mprotect
operation, very early on.
vault ~ # strace python
-- snip --
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7462000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb74626c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
mprotect(0xb7658000, 8192, PROT_READ) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
vault ~ # uname -a
Linux vault 2.6.31-gentoo-r10 #1 SMP Sun Mar 7 14:35:15 EST 2010 i686
Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux
I'm upgrading to the latest gentoo-sources. Only thing i'm worried about is
rebooting but all in the life of a gentoo user.
--
View this message in context:
http://gentoo.2317880.n4.nabble.com/updating-old-box-segfaults-with-python-tp274112p274799.html
Sent from the gentoo-user mailing list archive at Nabble.com.
[gentoo-user] Re: updating old box: segfaults with python
Stefan G. Weichinger xunil.at> writes: > yesterday I started to upgrade an older gentoo server at a customer. It > has only been updated now and then as they tend to save money and rarely > contact me ... > I would like to avoid to have to drive there so it would be great to be > able to fix that from here, via ssh. > Thanks for any help, Stefan Well it's probably late to "chime in" but, I have faced your delima too many time. I'm probably older and more of a grouch than your are but this problem is too simple. Build a second machine, with all they need, maybe a few new things. Copy the old data to the new machine. FEDEX (whatever) the machine to them. Since it is commercial and critical, no way in hell, I'd do this cheap. Teach them an expensive but excellent lesson. Let them keep the old box to do with as they like. They can even ship it to you every year or so for an upgrade. Redundancy is some thing I demand with commercial folks I deal with. Spare hardware onsite. Deploy one upgrade the other. PERIOD. They choose not to call, you have left them in good shape. The longer the duration between calls, the larger the invoice to fix. Customers like this are the reason many consultants/small firms go broke. "MAKE MONEY" and at the same time cultivate them into being a client you like having in your portfolio! Otherwise, ditch the loosers! or as they use to say money talks and bullshit walks... ymmv, hth, James
Re: [gentoo-user] Re: updating old box: segfaults with python
Am 09.01.2014 09:16, schrieb Helmut Jarausch: > Did you try www.sysresccd.org/ version 3.8.1? I'm not sure if it is > based on > glibc-2.17, yet. 2.15-r3 ... just booted it in a VM and looked it up.
Re: [gentoo-user] Re: updating old box: segfaults with python
Am 09.01.2014 11:15, schrieb Helmut Jarausch: > You can't test all of memory, especially not low memory. > But if you had a problem with some chip mapped to low memory > I doubt Linux would even boot. > Furthermore, memtester locks pages, i.e. it disables paging. > So the machine might not be very responsive during the tests. Yep, read the manpage ... the box has ~900 MB of RAM and I run "memtester 700M" for now. Loop1 ok, second Loop running ... thanks.
Re: [gentoo-user] Re: updating old box: segfaults with python
On 01/09/2014 10:59:45 AM, Stefan G. Weichinger wrote: Am 09.01.2014 09:16, schrieb Helmut Jarausch: > You can use sys-apps/memtester without physical access to the machine. > I had cases where memtester found errors which memtest86 didn't. > One of these cases was a machine which probably had a cache coherence > problem > since the error showed up only when more than one process ran memtester. > Replacing the CPU but not the memory fixed that problem. Thanks for the pointer ... how to use it to test the whole RAM? Just give it a value bigger than the available RAM or ... ? I just try it with a slightly lower value for now and will re-read the manpage. You can't test all of memory, especially not low memory. But if you had a problem with some chip mapped to low memory I doubt Linux would even boot. Furthermore, memtester locks pages, i.e. it disables paging. So the machine might not be very responsive during the tests.
Re: [gentoo-user] Re: updating old box: segfaults with python
Am 09.01.2014 09:16, schrieb Helmut Jarausch: > You can use sys-apps/memtester without physical access to the machine. > I had cases where memtester found errors which memtest86 didn't. > One of these cases was a machine which probably had a cache coherence > problem > since the error showed up only when more than one process ran memtester. > Replacing the CPU but not the memory fixed that problem. Thanks for the pointer ... how to use it to test the whole RAM? Just give it a value bigger than the available RAM or ... ? I just try it with a slightly lower value for now and will re-read the manpage. > Did you try www.sysresccd.org/ version 3.8.1? I'm not sure if it is > based on > glibc-2.17, yet. No, didn't take a look yet. Started my download now.
Re: [gentoo-user] Re: updating old box: segfaults with python
On 01/08/2014 11:39:21 PM, Stefan G. Weichinger wrote: Am 08.01.2014 19:47, schrieb Grant Edwards: > On 2014-01-08, Stefan G. Weichinger wrote: > >> Looking forward to some clever suggestions ;-) > > Well, I'd start by running memtest86 overnight just to eliminate the > possibility of marginal memory. But, if memory serves, this is a > remote server at a customer site -- so that may not be a viable > option. Sure. Good suggestion. I would do that if I had physical access to the server ... for now I don't. And I assume the box would behave much more problematic if the memory was faulty. You can use sys-apps/memtester without physical access to the machine. I had cases where memtester found errors which memtest86 didn't. One of these cases was a machine which probably had a cache coherence problem since the error showed up only when more than one process ran memtester. Replacing the CPU but not the memory fixed that problem. Did you try www.sysresccd.org/ version 3.8.1? I'm not sure if it is based on glibc-2.17, yet. Helmut.
Re: [gentoo-user] Re: updating old box: segfaults with python
Am 08.01.2014 19:47, schrieb Grant Edwards: > On 2014-01-08, Stefan G. Weichinger wrote: > >> Looking forward to some clever suggestions ;-) > > Well, I'd start by running memtest86 overnight just to eliminate the > possibility of marginal memory. But, if memory serves, this is a > remote server at a customer site -- so that may not be a viable > option. Sure. Good suggestion. I would do that if I had physical access to the server ... for now I don't. And I assume the box would behave much more problematic if the memory was faulty. So far it is "only" related to this python/glibc-issue. I emerge dozens of other packages without a problem in the last few hours. Thanks anyway ... if I have to run memtest and you were right I will let you know ;-) S
[gentoo-user] Re: updating old box: segfaults with python
On 2014-01-08, Stefan G. Weichinger wrote: > Looking forward to some clever suggestions ;-) Well, I'd start by running memtest86 overnight just to eliminate the possibility of marginal memory. But, if memory serves, this is a remote server at a customer site -- so that may not be a viable option. -- Grant Edwards grant.b.edwardsYow! ... the MYSTERIANS are at in here with my CORDUROY gmail.comSOAP DISH!!
