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
