David Dyer-Bennet wrote: > Nathan Davis <davisn at mailandnews.com> writes: > > > David Dyer-Bennet wrote: > > > > > "Matthew S. Hallacy" <poptix at techmonkeys.org> writes: > > > > > > > On Tue, Aug 06, 2002 at 01:19:24PM -0500, David Dyer-Bennet wrote: > > > > > > > > > I'm upgrading to glibc 2.2.4-27 (including the usual -common and > > > > > -devel; I don't use -profile). In fact I have it running now. rpm > > > > > --verify reports all three are installed fine. > > > > > > > > > > However, if I try to reinstall glibc using "rpm -U --replacepkgs > > > > > glibc-2.2.4-27.i386.rpm" I get "% post scriptlet failed", and if I try > > > > > -common I get "% pre scriptlet failed". When the first, at least, > > > > > happens, *everything* stops working (well, presumably every program > > > > > that depends on the glibc dynamic library; in fact a couple of > > > > > staticly linked programs I found do still run). > > > > > > > > > > > > > [snip] > > > > > > > > > I'm running now, but I believe my next upgrade will fail in the same > > > > > way, so I'd really like to figure out WTF is going on and fix it. > > > > > Anybody got a spare clue? > > > > > > > > Yes, I suspect you're using --nodeps and/or --force somewhere, that's > > > > a bad idea, instead you should use apt, or up2date to upgrade all of > > > > the packages that depend on $XYZ version of glibc at the same time. > > > > > > I didn't override any dependencies in the basic install. I certainly > > > have tried that when playing around trying to *recover* from the basic > > > install, but the problem appeared without that. > > > > > > Given that *every* dynamic process died in the bad cases, I don't > > > think it's a dependency of a particular program on a particular glibc > > > version. And the same dynamic binaries work when I copy over the > > > binaries from my alternate root. > > > > > > > Well, what version are you upgrading from? If it's a different so number, then > > binaries linked against the old version won't work with the new. Given that > > the installation was built against the old version, it is very likely that the > > cause of your problem is a version mismatch. You can try installing the new > > version, instead of upgrading it. > > Old version was 2.2.4-19, if I remember correctly. Might have been > -14; anyway 2.2.4 still. > Okay then, it looks like my hunch about different versions was wrong. > > Is it actually possible to remove glibc and then install a new > version? If so how? I thought the upgrade path was the only possible > route, since pretty much everything, including the tools rpm calls, > stop working when there's no glibc. > -- I've only tried to upgrade glibc once, and I ran into problems because I used rpm -U. This caused the machine to essentially no longer boot (because the new library had a different so-name, so there were dynamic linker errors). After fixing it via rescue disk, I believe I successfully "upgraded" by doing rpm -i. At least I remember this working for something (note: may have had to use --force, I don't remember). Basically, two versions of the package were installed -- satisfying the requirements for both old and new packages. FYI, the -U (--upgrade) option is really just a -e and -i, but done atomically from a dependency point of view. > > David Dyer-Bennet, dd-b at dd-b.net / New TMDA anti-spam in test > John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net > Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ > New Dragaera mailing lists, see http://dragaera.info > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20020806/7b9a3267/attachment.htm