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