[gentoo-user] updating old box: segfaults with python

[gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Greetings,

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 recommended to at least apply the stuff mentioned in the GLSAs ... and
applied some updates today (remote, via ssh).

Today glibc failed to merge:


>>> Installing (2 of 3) sys-libs/glibc-2.17
 * Defaulting /etc/host.conf:multi to on
/usr/lib/portage/bin/phase-functions.sh: Zeile 87: 26924
Speicherzugriffsfehler  "${PORTAGE_PYTHON:-/usr/bin/python}"
"${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}"
 * ERROR: sys-libs/glibc-2.11.3::gentoo failed (prerm phase):
 *   filter-bash-environment.py failed
 *
 * Call stack:
 *            ebuild.sh, line 480:  Called __preprocess_ebuild_env
 *   phase-functions.sh, line 156:  Called __filter_readonly_variables
'--filter-features' '--filter-locale' '--filter-path' '--filter-sandbox'
 *   phase-functions.sh, line 137:  Called die
 * The specific snippet of code:
 *   	"${PORTAGE_PYTHON:-/usr/bin/python}"
"${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" ||
die "filter-bash-environment.py failed"
 *
 * If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.11.3::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.11.3::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/environment'.
 * Working directory: '/usr/lib/portage/pym'
 * S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/work/glibc-2.11.3'
/usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 27001
Speicherzugriffsfehler  "$PORTAGE_BIN_PATH"/ebuild-ipc exit 1

But it seems that this is the consequence of problems with python.
There are various versions installed:

# eselect python list
Available Python interpreters:
  [1]   python2.4
  [2]   python2.5
  [3]   python2.6
  [4]   python2.7 *
  [5]   python3.1
  [6]   python3.3


But I get segfaults (german: Speicherzugriffsfehler) for all of them:

mail ~ # python2.7
Speicherzugriffsfehler
mail ~ # python3.1
Speicherzugriffsfehler
mail ~ # python3.3
Speicherzugriffsfehler

dmesg shows lines:

awk[28527]: segfault at 579e ip 0000579e sp bfc3006c error 4 in
gawk[8048000+4c000]
awk[28531]: segfault at 579e ip 0000579e sp bff3c8ec error 4 in
gawk[8048000+4c000]
find[28706]: segfault at 579e ip 0000579e sp bff21c3c error 4 in
find[8048000+21000]
find[28707]: segfault at 579e ip 0000579e sp bff42c9c error 4 in
find[8048000+21000]
find[28708]: segfault at 579e ip 0000579e sp bfe1a4ac error 4 in
find[8048000+21000]
find[28714]: segfault at 579e ip 0000579e sp bf82cb5c error 4 in
find[8048000+21000]
find[28715]: segfault at 579e ip 0000579e sp bfa0ef3c error 4 in
find[8048000+21000]
find[28716]: segfault at 579e ip 0000579e sp bfa4c4cc error 4 in
find[8048000+21000]
find[28720]: segfault at 579e ip 0000579e sp bfa1c83c error 4 in
find[8048000+21000]
find[28721]: segfault at 579e ip 0000579e sp bfcf9fbc error 4 in
find[8048000+21000]
eix[28731]: segfault at 579e ip 0000579e sp bfc028ec error 4 in
eix[8048000+114000]
python2.7[28732]: segfault at 579e ip 0000579e sp bfa1c9fc error 4 in
python2.7[8048000+1000]
python2.7[28733]: segfault at 579e ip 0000579e sp bf8a2c0c error 4 in
python2.7[8048000+1000]
python2.7[28746]: segfault at 579e ip 0000579e sp bfeb392c error 4 in
python2.7[8048000+1000]
python2.7[28747]: segfault at 579e ip 0000579e sp bfbfcd4c error 4 in
python2.7[8048000+1000]
python2.7[28749]: segfault at 579e ip 0000579e sp bfa1b71c error 4 in
python2.7[8048000+1000]
python2.7[28757]: segfault at 579e ip 0000579e sp bfeb8b0c error 4 in
python2.7[8048000+1000]
python2.7[28762]: segfault at 579e ip 0000579e sp bfeb479c error 4 in
python2.7[8048000+1000]



This leads to not being able to emerge something :-(

What can I do? quickpkg some python-version and copy over?
(sidenote: 32bit box ...)

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

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 12:28, schrieb Stefan G. Weichinger:

> What can I do? quickpkg some python-version and copy over?
> (sidenote: 32bit box ...)

I assume it should be glibc repaired, right?
Activated some 32bit-chroot here and building glibc-2.17-package now.

How to apply that without emerge? googling ...

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 4803 bytes --]

On Wednesday 08 Jan 2014 11:28:36 Stefan G. Weichinger wrote:
> Greetings,
> 
> 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 recommended to at least apply the stuff mentioned in the GLSAs ... and
> applied some updates today (remote, via ssh).
> 
> Today glibc failed to merge:
> >>> Installing (2 of 3) sys-libs/glibc-2.17
> 
>  * Defaulting /etc/host.conf:multi to on
> /usr/lib/portage/bin/phase-functions.sh: Zeile 87: 26924
> Speicherzugriffsfehler  "${PORTAGE_PYTHON:-/usr/bin/python}"
> "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}"
>  * ERROR: sys-libs/glibc-2.11.3::gentoo failed (prerm phase):
>  *   filter-bash-environment.py failed
>  *
>  * Call stack:
>  *            ebuild.sh, line 480:  Called __preprocess_ebuild_env
>  *   phase-functions.sh, line 156:  Called __filter_readonly_variables
> '--filter-features' '--filter-locale' '--filter-path' '--filter-sandbox'
>  *   phase-functions.sh, line 137:  Called die
>  * The specific snippet of code:
>  *   	"${PORTAGE_PYTHON:-/usr/bin/python}"
> "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" ||
> die "filter-bash-environment.py failed"
>  *
>  * If you need support, post the output of `emerge --info
> '=sys-libs/glibc-2.11.3::gentoo'`,
>  * the complete build log and the output of `emerge -pqv
> '=sys-libs/glibc-2.11.3::gentoo'`.
>  * The complete build log is located at
> '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/temp/environment'.
>  * Working directory: '/usr/lib/portage/pym'
>  * S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.11.3/work/glibc-2.11.3'
> /usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 27001
> Speicherzugriffsfehler  "$PORTAGE_BIN_PATH"/ebuild-ipc exit 1
> 
> But it seems that this is the consequence of problems with python.
> There are various versions installed:
> 
> # eselect python list
> Available Python interpreters:
>   [1]   python2.4
>   [2]   python2.5
>   [3]   python2.6
>   [4]   python2.7 *
>   [5]   python3.1
>   [6]   python3.3
> 
> 
> But I get segfaults (german: Speicherzugriffsfehler) for all of them:
> 
> mail ~ # python2.7
> Speicherzugriffsfehler
> mail ~ # python3.1
> Speicherzugriffsfehler
> mail ~ # python3.3
> Speicherzugriffsfehler
> 
> dmesg shows lines:
> 
> awk[28527]: segfault at 579e ip 0000579e sp bfc3006c error 4 in
> gawk[8048000+4c000]
> awk[28531]: segfault at 579e ip 0000579e sp bff3c8ec error 4 in
> gawk[8048000+4c000]
> find[28706]: segfault at 579e ip 0000579e sp bff21c3c error 4 in
> find[8048000+21000]
> find[28707]: segfault at 579e ip 0000579e sp bff42c9c error 4 in
> find[8048000+21000]
> find[28708]: segfault at 579e ip 0000579e sp bfe1a4ac error 4 in
> find[8048000+21000]
> find[28714]: segfault at 579e ip 0000579e sp bf82cb5c error 4 in
> find[8048000+21000]
> find[28715]: segfault at 579e ip 0000579e sp bfa0ef3c error 4 in
> find[8048000+21000]
> find[28716]: segfault at 579e ip 0000579e sp bfa4c4cc error 4 in
> find[8048000+21000]
> find[28720]: segfault at 579e ip 0000579e sp bfa1c83c error 4 in
> find[8048000+21000]
> find[28721]: segfault at 579e ip 0000579e sp bfcf9fbc error 4 in
> find[8048000+21000]
> eix[28731]: segfault at 579e ip 0000579e sp bfc028ec error 4 in
> eix[8048000+114000]
> python2.7[28732]: segfault at 579e ip 0000579e sp bfa1c9fc error 4 in
> python2.7[8048000+1000]
> python2.7[28733]: segfault at 579e ip 0000579e sp bf8a2c0c error 4 in
> python2.7[8048000+1000]
> python2.7[28746]: segfault at 579e ip 0000579e sp bfeb392c error 4 in
> python2.7[8048000+1000]
> python2.7[28747]: segfault at 579e ip 0000579e sp bfbfcd4c error 4 in
> python2.7[8048000+1000]
> python2.7[28749]: segfault at 579e ip 0000579e sp bfa1b71c error 4 in
> python2.7[8048000+1000]
> python2.7[28757]: segfault at 579e ip 0000579e sp bfeb8b0c error 4 in
> python2.7[8048000+1000]
> python2.7[28762]: segfault at 579e ip 0000579e sp bfeb479c error 4 in
> python2.7[8048000+1000]
> 
> 
> 
> This leads to not being able to emerge something :-(
> 
> What can I do? quickpkg some python-version and copy over?
> (sidenote: 32bit box ...)
> 
> 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

The segfaults look scary and could point to hardware fault.  I'd run a backup 
of any useful data to start with.

Then run 'python-updater' to rebuild any packages that had their links broken.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 683 bytes --]

On Wednesday 08 Jan 2014 11:39:03 Stefan G. Weichinger wrote:
> Am 08.01.2014 12:28, schrieb Stefan G. Weichinger:
> > What can I do? quickpkg some python-version and copy over?
> > (sidenote: 32bit box ...)
> 
> I assume it should be glibc repaired, right?
> Activated some 32bit-chroot here and building glibc-2.17-package now.
> 
> How to apply that without emerge? googling ...

In case things are really badly borked:

  http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml

Then you can use emerge --buildpkg to create a binary package locally, and scp 
it to the remote machine where you can use --usepkg or --usepkgonly.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 12:45, schrieb Mick:

> The segfaults look scary and could point to hardware fault.  I'd
> run a backup of any useful data to start with.

sure, backups ran late night ... and non-python-stuff seems to work ok
so far

> Then run 'python-updater' to rebuild any packages that had their
> links broken.

That does not run. Already tried it.

# python-updater
/usr/sbin/python-updater: Zeile 146: 28887 Speicherzugriffsfehler
/usr/bin/portageq has_version / "${1}"
/usr/sbin/python-updater: Zeile 146: 28888 Speicherzugriffsfehler
/usr/bin/portageq has_version / "${1}"
 * Python 2 and Python 3 not installed

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 12:53, schrieb Mick:

> In case things are really badly borked:
> 
> http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml
>
>  Then you can use emerge --buildpkg to create a binary package
> locally, and scp it to the remote machine where you can use
> --usepkg or --usepkgonly.

Thanks for the pointer.

Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc

Still getting segfaults with the replaced emerge-command :-(

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 554 bytes --]

On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote:

> Thanks for the pointer.
> 
> Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc
> 
> Still getting segfaults with the replaced emerge-command :-(

This does not look good.

Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD 
for you to connect to it remotely and then chroot into the borked installation 
to essentially reinstall the required packages with a functional portage and 
toolchain from the LiveCD?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 785 bytes --]

On Wednesday 08 Jan 2014 12:06:47 Mick wrote:
> On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote:
> > Thanks for the pointer.
> > 
> > Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now etc
> > 
> > Still getting segfaults with the replaced emerge-command :-(
> 
> This does not look good.
> 
> Can you get someone to reboot the machine with a sysrescue or Gentoo LiveCD
> for you to connect to it remotely and then chroot into the borked
> installation to essentially reinstall the required packages with a
> functional portage and toolchain from the LiveCD?

Another idea, in case you have a fs corruption:  if awk/gawk segfaults can you 
use a binary package from your local machine to see if the segfault goes away?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 13:06, schrieb Mick:
> On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote:
> 
>> Thanks for the pointer.
>> 
>> Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now
>> etc
>> 
>> Still getting segfaults with the replaced emerge-command :-(
> 
> This does not look good.
> 
> Can you get someone to reboot the machine with a sysrescue or
> Gentoo LiveCD for you to connect to it remotely and then chroot
> into the borked installation to essentially reinstall the required
> packages with a functional portage and toolchain from the LiveCD?

maybe ... *but* I think I got something done:

pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org
... and untarred it ... didn't help.

Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge
... don't segfault anymore.

I will now re-emerge glibc and python etc ... right?

Thanks!

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1252 bytes --]

On Wednesday 08 Jan 2014 12:10:41 Stefan G. Weichinger wrote:
> Am 08.01.2014 13:06, schrieb Mick:
> > On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote:
> >> Thanks for the pointer.
> >> 
> >> Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now
> >> etc
> >> 
> >> Still getting segfaults with the replaced emerge-command :-(
> > 
> > This does not look good.
> > 
> > Can you get someone to reboot the machine with a sysrescue or
> > Gentoo LiveCD for you to connect to it remotely and then chroot
> > into the borked installation to essentially reinstall the required
> > packages with a functional portage and toolchain from the LiveCD?
> 
> maybe ... *but* I think I got something done:
> 
> pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org
> ... and untarred it ... didn't help.
> 
> Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge
> ... don't segfault anymore.
> 
> I will now re-emerge glibc and python etc ... right?
> 
> Thanks!

I don't know if I am stating the obvious but just in case:  Have a look here 
and set up your --python2 to reflect what you have installed.  You may need to 
go at it in steps between versions.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1474 bytes --]

On Wednesday 08 Jan 2014 13:33:20 Mick wrote:
> On Wednesday 08 Jan 2014 12:10:41 Stefan G. Weichinger wrote:
> > Am 08.01.2014 13:06, schrieb Mick:
> > > On Wednesday 08 Jan 2014 11:58:01 Stefan G. Weichinger wrote:
> > >> Thanks for the pointer.
> > >> 
> > >> Unpacked /usr/portage/distfiles/portage-2.2.7.tar.bz2 right now
> > >> etc
> > >> 
> > >> Still getting segfaults with the replaced emerge-command :-(
> > > 
> > > This does not look good.
> > > 
> > > Can you get someone to reboot the machine with a sysrescue or
> > > Gentoo LiveCD for you to connect to it remotely and then chroot
> > > into the borked installation to essentially reinstall the required
> > > packages with a functional portage and toolchain from the LiveCD?
> > 
> > maybe ... *but* I think I got something done:
> > 
> > pulled in python-2.7.5-r3.tbz2 from http://tinderbox.dev.gentoo.org
> > ... and untarred it ... didn't help.
> > 
> > Then glibc-2.16.0.tbz2 ... and now python-updater and eix and emerge
> > ... don't segfault anymore.
> > 
> > I will now re-emerge glibc and python etc ... right?
> > 
> > Thanks!
> 
> I don't know if I am stating the obvious but just in case:  Have a look
> here and set up your --python2 to reflect what you have installed.  You
> may need to go at it in steps between versions.

Oops!  Pulled the trigger too fast - sorry:

 http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 14:36, schrieb Mick:

>> I don't know if I am stating the obvious but just in case:  Have
>> a look here and set up your --python2 to reflect what you have
>> installed.  You may need to go at it in steps between versions.
> 
> Oops!  Pulled the trigger too fast - sorry:
> 
> http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml

Yep.

I tried to install glibc-2.17 again and it failed again.
Re-applied the 2.16-tarball ...

python-3.3.2-r2 emerged fine, I assume I should also re-emerge
dev-lang/python:2.7 ?

Re: [gentoo-user] updating old box: segfaults with python

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Wed, 08 Jan 2014 12:54:09 +0100, Stefan G. Weichinger wrote:

> # python-updater
> /usr/sbin/python-updater: Zeile 146: 28887 Speicherzugriffsfehler
> /usr/bin/portageq has_version / "${1}"
> /usr/sbin/python-updater: Zeile 146: 28888 Speicherzugriffsfehler
> /usr/bin/portageq has_version / "${1}"
>  * Python 2 and Python 3 not installed

Is eselect python pointing to valid python 2 and 3 versions? Can you run
python2 and python3 in a terminal?


-- 
Neil Bothwick

When told the reason for Daylight Saving time the old Indian said...
"Only a white man would believe that you could cut a foot off the top of a
blanket And sew it to the bottom of a blanket and have a longer blanket."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 17:20, schrieb Neil Bothwick:
> On Wed, 08 Jan 2014 12:54:09 +0100, Stefan G. Weichinger wrote:
> 
>> # python-updater /usr/sbin/python-updater: Zeile 146: 28887
>> Speicherzugriffsfehler /usr/bin/portageq has_version / "${1}" 
>> /usr/sbin/python-updater: Zeile 146: 28888
>> Speicherzugriffsfehler /usr/bin/portageq has_version / "${1}" *
>> Python 2 and Python 3 not installed
> 
> Is eselect python pointing to valid python 2 and 3 versions? Can
> you run python2 and python3 in a terminal?

Yes, since untaring glibc-2.16.

glibc-2.17 does not emerge  --- it fails and leaves me with the
segfaults ... only fix so far is unpacking that 2.16-tarball

http://tinderbox.dev.gentoo.org/default-linux/x86/sys-libs/ only has
2.16 ... portage on the given system "thinks" 2.17 is installed so I
can't (re-)emerge 2.16 because downgrading is not supported.

I don't want to keep it this way as it isn't really consistent ... so
I should find out why glibc-2.17 does not install, right?

trying "emerge -B glibc" for now ... step by step.

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 17:41, schrieb Stefan G. Weichinger:

> trying "emerge -B glibc" for now ... step by step.

emerge -B : success

emerge -K: same failure

The unpacking of glibc seems to somehow break python while emerge still
runs ... at least that is my impression.

Manually unpacking the 2.17-tarball does not fix python ...

So I am back with the manual glibc-2.16 ... and have the correctly built
glibc-2.17.tbz2 as well.

So how to fix that?

Use another python? Right now I have:

# eselect python list

Available Python interpreters:
  [1]   python2.4
  [2]   python2.5
  [3]   python2.6
  [4]   python2.7 *
  [5]   python3.1
  [6]   python3.2
  [7]   python3.3

In make.conf:

PYTHON_TARGETS="python2_6 python2_7 python3_2"
PYTHON_SINGLE_TARGET="python2_7"

I assume I could get rid of some releases ... but currently I am
hesitating ;-)

2.7.5-r3 and 3.2.5-r3 rebuilt fine here today.

used python-3.2 now ... next failure to install the tbz2

What do I get?

->


>>> Installing (1 of 1) sys-libs/glibc-2.17
 * Defaulting /etc/host.conf:multi to on
 * ERROR: sys-libs/glibc-2.17::gentoo failed (prerm phase):
 *   eutils.eclass could not be found by inherit()
 *
 * Call stack:
 *           ebuild.sh, line 545:  Called source
'/var/db/pkg/sys-libs/glibc-2.17/glibc-2.17.ebuild'
 *   glibc-2.17.ebuild, line   5:  Called inherit 'eutils' 'versionator'
'toolchain-funcs' 'flag-o-matic' 'gnuconfig' 'multilib' 'systemd'
'unpacker' 'multiprocessing'
 *           ebuild.sh, line 257:  Called die
 * The specific snippet of code:
 *   		[[ -z ${location} ]] && die "${1}.eclass could not be found by
inherit()"
 *
 * If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.17::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.17::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/temp/die.env'.
 * Working directory: '/usr/lib/portage/pym'
 * S: '/var/tmp/portage/._unmerge_/sys-libs/glibc-2.17/work/glibc-2.17'
/usr/lib/portage/bin/isolated-functions.sh: Zeile 109: 17558
Speicherzugriffsfehler  "$PORTAGE_BIN_PATH"/ebuild-ipc exit 1
 * The ebuild phase 'prerm' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
 * QA Notice: ECLASS 'eutils' inherited illegally in sys-libs/glibc-2.17
 * ERROR: sys-libs/glibc-2.17::gentoo failed:
 *   eutils.eclass could not be found by inherit()
 *
 * Call stack:
 *   misc-functions.sh, line  17:  Called source
'/usr/lib/portage/bin/ebuild.sh'
 *           ebuild.sh, line 545:  Called source
'/var/db/pkg/sys-libs/glibc-2.17/glibc-2.17.ebuild'
 *   glibc-2.17.ebuild, line   5:  Called inherit 'eutils' 'versionator'
'toolchain-funcs' 'flag-o-matic' 'gnuconfig' 'multilib' 'systemd'
'unpacker' 'multiprocessing'
 *           ebuild.sh, line 257:  Called die
 * The specific snippet of code:
 *   		[[ -z ${location} ]] && die "${1}.eclass could not be found by
inherit()"
 *


... and way more.

I tried to remove /var/db/pkg/sys-libs/glibc-2.17/environment.bz2 ...
didn't help.

Looking forward to some clever suggestions ;-)

Stefan

[gentoo-user] Re: updating old box: segfaults with python

[Grant Edwards]

On 2014-01-08, Stefan G. Weichinger <lists@xunil.at> 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.edwards        Yow! ... the MYSTERIANS are
                                  at               in here with my CORDUROY
                              gmail.com            SOAP DISH!!

Re: [gentoo-user] Re: updating old box: segfaults with python

[Stefan G. Weichinger]

Am 08.01.2014 19:47, schrieb Grant Edwards:
> On 2014-01-08, Stefan G. Weichinger <lists@xunil.at> 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

Re: [gentoo-user] updating old box: segfaults with python

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1094 bytes --]

On Wednesday 08 Jan 2014 14:37:00 Stefan G. Weichinger wrote:
> Am 08.01.2014 14:36, schrieb Mick:
> >> I don't know if I am stating the obvious but just in case:  Have
> >> a look here and set up your --python2 to reflect what you have
> >> installed.  You may need to go at it in steps between versions.
> > 
> > Oops!  Pulled the trigger too fast - sorry:
> > 
> > http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
> 
> Yep.
> 
> I tried to install glibc-2.17 again and it failed again.
> Re-applied the 2.16-tarball ...
> 
> python-3.3.2-r2 emerged fine, I assume I should also re-emerge
> dev-lang/python:2.7 ?

If dev-lang/python:2.7 does not allow you to emerge glibc then use eselect to 
switch --python2 to an older python available in that box and try emerging 
glibc with that.  You may have to repeat this until successful (hopefully) 
with dev-lang/python:2.7.

I don't know if you would need to update glibc in smaller steps (I can't 
recall how many versions were there in between) but this can be a painful 
process.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: updating old box: segfaults with python

[Helmut Jarausch]

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 <lists@xunil.at> 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

[Stefan G. Weichinger]

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

[Helmut Jarausch]

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] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 09.01.2014 08:07, schrieb Mick:

> If dev-lang/python:2.7 does not allow you to emerge glibc then use
> eselect to switch --python2 to an older python available in that
> box and try emerging glibc with that.  You may have to repeat this
> until successful (hopefully) with dev-lang/python:2.7.

> I don't know if you would need to update glibc in smaller steps (I
> can't recall how many versions were there in between) but this can
> be a painful process.

It already is ... I face problems with postfix now ... needing another
kernel leading to the udev-upgrade needing other kernel-option(s) ...
you know.

I only have python 2.7 / 3.2 / 3.3 now installed.

glibc-2.17 *builds* OK (emerge -B) but does not install ... when I
read correctly it does not find the class eutils.class (which is there
...).

The memory seems OK to me ...

Re: [gentoo-user] Re: updating old box: segfaults with python

[Stefan G. Weichinger]

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

[Stefan G. Weichinger]

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] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 09.01.2014 11:16, schrieb Stefan G. Weichinger:

> glibc-2.17 *builds* OK (emerge -B) but does not install ... when I
> read correctly it does not find the class eutils.class (which is there
> ...).

Additional:

I would not mind staying with 2.16 ... as I run with it right now, it is
only portage "thinking" to have 2.17 installed ... but downgrading is
hard-masked.

Re: [gentoo-user] updating old box: segfaults with python

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Thu, 09 Jan 2014 11:16:01 +0100, Stefan G. Weichinger wrote:

> I only have python 2.7 / 3.2 / 3.3 now installed.

Bear n mind that portage will stick with python2, whatever your eselect
settings, unless you emerged it with the python3 USE flag.


-- 
Neil Bothwick

WINDOWS: Will Install Needless Data On Whole System

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Portage & Python3 - WAS: Re: [gentoo-user] updating old box: segfaults with python

[Tanstaafl]

On 2014-01-09 6:29 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> Bear n mind that portage will stick with python2, whatever your eselect
> settings, unless you emerged it with the python3 USE flag.

I have wondered...

Is there any plan to eventually move portage to python3? It isn't like 
python3 hasn't been out for a while now... ;)

Re: [gentoo-user] updating old box: segfaults with python

[Stefan G. Weichinger]

Am 09.01.2014 12:29, schrieb Neil Bothwick:
> On Thu, 09 Jan 2014 11:16:01 +0100, Stefan G. Weichinger wrote:
> 
>> I only have python 2.7 / 3.2 / 3.3 now installed.
> 
> Bear n mind that portage will stick with python2, whatever your
> eselect settings, unless you emerged it with the python3 USE flag.

Yes.

What I did now: went back to gcc-4.4.4-r2 (built in 2010) and rebuilt
both dev-lang/python:2.7 and dev-lang/python:3.2

So I should have python built against the current unpacked glibc-2.16,
right?

Now I could retry to upgrade to glibc-2.17 ... and see if I hit that
missing eutils.eclass again.

Re: Portage & Python3 - WAS: Re: [gentoo-user] updating old box: segfaults with python

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Thu, 09 Jan 2014 06:59:16 -0500, Tanstaafl wrote:

> Is there any plan to eventually move portage to python3? It isn't like 
> python3 hasn't been out for a while now... ;)

USE="python3" emerge -1 portage

I've been sing that for a long time, but this is Gentoo, it is up to the
individual to decide which version they use.


-- 
Neil Bothwick

Always remember you're unique, just like everyone else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: updating old box: segfaults with python

[James]

Stefan G. Weichinger <lists <at> 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

[gentoo-user] Re: updating old box: segfaults with python

[lovely2]

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.

Re: [gentoo-user] Re: updating old box: segfaults with python

[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.

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.9999    | o o o o o o o o o o o o o o | o 3.4.9999  | 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.10.27   | gentoo
--------------+-----------------------------+-------------+-------
 3.10.9999    | o o o o o o o o o o o o o o | o 3.10.9999 | gentoo
--------------+-----------------------------+-------------+-------
   3.11.10    | ~ ~ ~ o ~ ~ o ~ ~ ~ ~ ~ ~ ~ | o 3.11.10   | gentoo
--------------+-----------------------------+-------------+-------
 3.11.9999    | o o o o o o o o o o o o o o | o 3.11.9999 | gentoo
--------------+-----------------------------+-------------+-------
    3.12.7    | ~ ~ ~ o ~ ~ o ~ ~ ~ ~ ~ ~ ~ | o 3.12.7    | gentoo
--------------+-----------------------------+-------------+-------
    3.12.8    | ~ ~ ~ o ~ ~ o ~ ~ ~ ~ ~ ~ ~ | o 3.12.8    | gentoo
--------------+-----------------------------+-------------+-------
 3.12.9999    | o o o o o o o o o o o o o o | o 3.12.9999 | gentoo


Dan

[gentoo-user] Re: updating old box: segfaults with python [Solved] for me at least.

[lovely2]

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

[Stefan G. Weichinger]

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