Problem with glibc 2.3.1 being autocleaned+a few suggestions

Princess Firefly · Tux's lil' helper Joined: 21 Apr 2002 Posts: 80

First a couple of related suggestions that would have saved me a few hours of headache today:

1. Update should not remove newer versions of programs to install older ones, especially with autoclean being turned on by default. (so, for example, I have audacity 1.0.0-r2 installed, emerge rsync overwrites my package.mask file so if I forget to edit it again trying to "update world" tries to uninstall 1.0.0-r2 and install 1.0.0-r1 which is obivously not a desirable default action. Or like how yesterday emerge -u world somehow decided to remove glibc 2.3.1 and install glibc 2.2.5 and wreck my whole system).

2. I love gentoo and optimizing programs by building from source but: there should be the ability to downloaded pre-compiled i386 binaries for major system programs/libraries. If you cannot use emerge because glibc/gcc/whatever aren't working, you're hosed, you can't fix anything. This might be a nice feature for other programs too in some cases.

Ok, on to my fun with glibc, this is what I think happened, I may be off a bit but generally I think I've got it.

I did an update world yesterday and emerge, for some reason, decided that I needed glibc 2.2.5 (even though I had 2.3.1 installed) and emerged that. Well, autoclean figured since I just installed 2.2.5 I didn't need 2.3.1 anymore so it removed it. This resulted in a slew of "GLIBC_2.3 Needed" errors for such various applications as init, mount, gcc, mozilla, evolution, etc. etc.

Since I could no longer boot the system (kernel panic because init needs glibc 2.3) I booted from the 1.4a cdrom. Once I figured out what happened I figured it'd just be a matter of emerging glibc 2.3.1 again. No problem, except that after chroot'ing into my old system emerge couldn't compile anything because I didn't have glibc 2.3 installed (chicken or the egg, can't compile glibc 2.3 because you need glibc 2.3 to compile). This where the ability to download a precompiled glibc would have been very nice.

Here's how I fixed the problem in case anyone is in the same boat:

- boot with the 1.4a cd, mount your old system and chroot into it
- Back up bin, sbin, lib, usr (ex. "mv lib libback")
- untar the stage 2 tarball from the installation CD to a temporary directory
- copy the bin, sbin, lib, and usr directories from the tarball to your system.

You now have a pretty empty but at least functional glibc 2.2.5 system.

- copy the portage directory from your backed up usr directory to your new 'clean' usr directory (for me it was cp -r /usrback/portage /usr)
- emerge glibc 2.3.1 (ebuild /usr/portage/sys-libs/glibc/glibc-2.3.1-r1.ebuild merge)

Hopefully the compile will work. If it does, you now have a basically empty system BUT it has glibc 2.3.1. The trick now is to copy all of your old system back except for the glibc 2.3.1 files now that you have them. Since I don't know what files glibc makes I did this as follows:

- exit out of chroot (type exit).
- backup the lib directory of your 'new' system (with glibc 3.2.1) (cp -r lib libcleanback)
- delete lib, (rm -rf lib)
- copy the lib from your old system back (cp -r libback lib)
- now copy the files from libcleanback (the lib from your 'new' system) to lib. (cd libcleanback; cp * ../lib)

- get rid of bin, sbin, and usr (ex. rm -rf bin)
- get you're old directories back, ie the ones you backed-up (ex. mv binback bin)
- you could delete libcleanback now but leave it for now just in case you messed up (it took me three tries) otherwise you'll have to recompile glibc again which takes forever
- unmount system and reboot

Hopefully most things will work now, there's only one more step

- run "ldconfig"

My systems back up and running like nothing happened. What a waste of a day. Hopefully this helps someone and the great folks at gentoo will fix autoclean and update so they don't replace newer versions with older ones.

hearts,
xpfx

rac · Posted: Mon Nov 04, 2002 6:16 am Post subject:

Thanks for posting this - it'll probably save a few people some headaches. I think if one can spare the disk space, it's a good idea to emerge with the -b option at least for critical packages - that way you have your own binary backups.
_________________
For every higher wall, there is a taller ladder

faz · Posted: Sat Nov 09, 2002 12:23 pm Post subject:

It sure saved my day!! Thanx a million!

I noticed you didn't know what files where created by glibc. This thread answers that: https://forums.gentoo.org/viewtopic.php?t=19662&start=50 It also seems wise to rebuild glibc-2.3.1 on you're rescued install after reboot So all you're optimazation flags are being used again.

lx · Posted: Sat Nov 09, 2002 12:52 pm Post subject:

Maybe it would be wise to let the bootstrap packages (especially gcc and glibc) always automatically be compiled with the -b option. Or else post a warning or put it in the install documentation (if it's not already in, I haven't read it lately, cause I don't need to re-install, don't you love linux), losing / destroying a file of these packages is a major pain in the rear. It's less then 50 Mb to store these important files and can save your life (well system).

Cya lX.

Ps: I always (re)build crucial (and very big) packages with the -b option.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa

Kumba · Posted: Sun Nov 10, 2002 8:25 am Post subject:

What are the advantages of moving up to Glibc 2.3.x anyways? Are there any changes as drastic as the GCC 3.2 upgrade? If I upgraded a machine to Glibc 2.3.x, would it be wise to attempt an emerge -e world?

--Kumba
_________________
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic

lx · Posted: Sun Nov 10, 2002 8:42 am Post subject:

I did a emerge -be world (well sort of / not all at once/ first bootstrap packages then system then remaining world). And (luckely it succeeded), but since glibc is at the base of a gnu/linux system, it remains a tricky operation / I was even prepared as a last resort to install my system from scratch if it went wrong and I also had binary (-b) packages of the crucial packages. Better what till it's stable, although MY system runs fine, I don't know how other systems will cope.

btw. I'm running unstable (ACCEPT_KEYWORDS="~x86")]

Advantage???? it's newer, but if your systems runs fine don't change it.
I'm just living on the edge..... :wink:

Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa

zen_guerrilla · Guru Joined: 18 Apr 2002 Posts: 343 Location: Greece

I' m thinking of upgrading to unstable branch tonight (I'm fetching the sources now), mainly because I want to build kde-3.1rc2 w/ malloc=full & after all, living on the edge is fun

. Should a simple "emerge world -u" work or do I need to rebuild everything after emerging glibc,gettext,gcc & binutils ?

.:: zen ::.

lx · Posted: Tue Nov 12, 2002 4:15 pm Post subject:

zen_guerrilla · Guru Joined: 18 Apr 2002 Posts: 343 Location: Greece

IX: With bootstrap u mean /usr/portage/scripts/bootstrap.sh or USE="bootstrap" emerge gettext binutils gcc glibc ? Because I think that the bootstrap.sh script takes care of the portage profile info & not /etc/make.conf (except for C**FLAGS).

However, could someone pls tell me which packages are statically linked to glibc (based on his/hers upgrade -> unstable experience) so that I could emerge only these ? I don't want to spend the next 2 days emerging -e world

.:: zen ::.

lx · Posted: Tue Nov 12, 2002 9:37 pm Post subject:

zen_guerrilla · Guru Joined: 18 Apr 2002 Posts: 343 Location: Greece

choward · Tux's lil' helper Joined: 08 Nov 2002 Posts: 92

rac · Posted: Wed Nov 20, 2002 5:58 am Post subject:

This may have something to do with glibc's versioned symbols. IIRC, this is a way to allow relatively seamless backward compatibility when changing function signatures. Say function f() used to be f(int) in version 1.0 of glibc and is now f(int,char) in version 2.0. The problem is how to allow libraries compiled against glibc 1.0 to be able to run when linked against 2.0. The way it works internally (I think) is similar to C++ name mangling, where the actual function name linked against is f_GLIBC_1_0.

All that glibc 2.0 has to provide, then, is f_GLIBC_1_0(int) and f_GLIBC_2_0(int,char), and both applications compiled against 1.0 and 2.0 work, even though the function signature and calling convention of the same named function f has completely changed.

Therefore, I think what you're seeing with the 2.0 and 2.1 stuff is that later versions are implementing those older versioned symbols as well, so that apps compiled against 2.0 and 2.1 will still run when linked against 2.2+.
_________________
For every higher wall, there is a taller ladder

je4d · n00b Joined: 28 Aug 2002 Posts: 26

yep, i was in the same boat, thanks a million firefly ;-)

it chooses glibc2.2.x if you're not using testing (ACCEPT_KEYORDS="~x86" in make.conf). does anyone know how to put a system on glibc2.3.1 and stuff back to glibc2.2.x safely so i can stop using testing?

je4d

discostu · Guru Joined: 01 Nov 2002 Posts: 333

I had a similar problem. I accidentally unmerged glibc. I did what Princess Firefly suggested and now my computer boots! Thanks!

.

However, I seem to have lost some functionality (such as X not starting, cdrecord -scanbus not working, etc). Rather than fix it all I've decided to just upgrade from 1.1a to 1.4. Should I use the livecd? or would it be alright just to do the upgrade scripts from http://www.gentoo.org/doc/en/upgrade-to-gentoo-1.4.xml.