SONAME error when upgrading a long time unsync-ed system

[Ronen Itzhaki]

We were synchronizing a system that hasn't been synced for about 3.5 years (production servers).
Emerging everything isn't an option, so we started building an upgrade script for all of our production servers, by solving the (obviously expected) many many issues, one by one - not an easy task...
Yet, we've ran into a problem we do not know how to resolve -
The following error appeared while upgrading bzip2:

>>> Install bzip2-1.0.6-r7 into /var/tmp/portage/app-arch/bzip2-1.0.6-r7/image/ category app-arch
* amd64: running multilib-minimal_abi_src_install
* ERROR: app-arch/bzip2-1.0.6-r7::gentoo failed (install phase):
* unable to read SONAME from libbz2.so

The libbz2.so Is being built with a SONAME:

cmd> objdump /var/tmp/portage/app-arch/bzip2-1.0.6-r7/work/bzip2-1.0.6-amd64/libbz2.so.1.0 -p | grep SONAME
SONAME libbz2.so.1

There's no sign in the ebuilds for using -Wl or -soname ... inside.

It might be that some of portage tools needs to be updated (that effects ebuild functions gen_usr_ldscript , doins maybe?).

The bzip2 creates a dependency problems that effect everything...

Any idea?

Thanks.
_________________
Ronen.

[VinzC]

Hi.

Given how long the server has stayed un-sync'ed I'd prepare the task, say, in a virtual machine clone. There's been so many components that changed inbetween that it's best to prepare the system for a complete replacement after it's upgraded safely aside on an inactive, temporary host.

Portage is the main component and brings its all lot of features, like keep out-of-date libraries until they're not needed, revdep-rebuild broken packages, aso. It's best to start with it before anything else. Of course, you'll see it wants to upgrade quite a bunch of things from that. Unfortunately and since every case is different, there's no golden rule I can give you unless patiently sort this out in a clone host, hence my suggestion.

After your cloned host has been successfully upgraded, you might upgrade it using the pre-compiled packages from the cloned host. You can safely include configuration files since it's the very same system.

If that's not an option, you can always download binaries from a Gentoo binary repository for problematic packages.

At least, that's how I would do.

Hope this helps
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

[steveL]

Have to say I'd simply reinstall, by bringing up a new install that has all the packages you need on it, testing it to ensure it runs what you need and looping for a while, and then clone that, phasing out old servers for their replacement running side-by-side for a bit, one at a time (since more care needs to be taken for each individual machine and its data as you get to it.)

Strikes me as less work and more generic, so useful for future. A custom script to get you through this situation isn't going to be useful ever again.

Sorry if I'm missing some aspect not mentioned so far; I'm assuming they're all the same setup, or you wouldn't be writing a script to do the custom upgrade for all of them.

[Ronen Itzhaki]

Hi,
Reinstalling is no option, as I mentioned - production servers are at stake.
Anyway, it seems like the bin pkg solved the problem (for now...)

So, thanks VinzC!
_________________
Ronen.

[steveL]

[Ronen Itzhaki]

Hello

As I stated, we went for the binary repo for filling in the uncompiled libs.
Question is- what packages are related to the gcc tool-chain or portage that can solve this? (like maybe app-portage category and such..)

Thanks.
_________________
Ronen.