> * * * * * > > > > > So to clean up this system, would I: > > > > > 1. remove ALL 2.11.2 files in /lib (making sure there are no > > > > > symlinks to them). > > > > > 2. NOW, re-upgrade to 2.13-7 > > > > > > > > > > What happened before: > > > > > 1. I myself placed the 2.11.2 files from the live CD. > > > > > > The question is why did you do that initially? Because of a failed > > > upgrade to version 2.13-6 or -7 or for an unrelated issue? > > > > I did that to get a working shell, system again. > > When did you got the initial problem? When upgrading from 2.13-6? from > 2.13-7? When the 2.13-6 upgrade failed, I accidently (my fault) lost a file. When I could not find it from where I can moved it (it was there, in fact a symlink I could have remade easily enough but ...) I copied the 2.11 files to get up and running again. > > > > > > 2. Subsequent upgrade to 2.13-7 LEFT SYMLINKS TO THESE, apparently. > > > > > > Actually ldconfig creates links for 2.11.2 files in /lib. We have a > > > script to detect old ld.so in /lib, it looks like we have to extend it > > > for all files from libc6. > > > > If I am upgrading away from 2.11, then I obviously do NOT want these. > > When upgrading from 2.11, the files are removed by dpkg, and thus are > not created. In your case you added the files manually, so they were not > handled by dpkg. OK, but there very presense stimulated ldconfig or whateve to symlink them and that was fatal!
> > > > > OK, I did it. The 2.11.2 files were left around for now, nothing > > > > symlinks to them. > > > > > > > > It was a bit hairy over the original bug for the non-dpkg-owned > > > > ld.so... Removing it always left me hosed. Finally replaced the > > > > ld-linux one with the > > > > > > ld.so actually had to be removed, but some more files with it. > > > > The original bug: > > Action: Remove and then try again -- this will leave many/most users with > > a hosed system! > > Alternatives: > > Place proper ld-linux and then remove obselete ld.so stuff -- This is > > what I discovered. Script could do this. > > Leave alone and proceed -- could be dangerous so the above is best. > > When did you get this issue exactly? It is true that 2.13-6 leaves the > ld.so and thus might break the system, but 2.13-7 refuses to upgrade in > that case. 2.13-6 refused to proceed but with a more cryptic error message 2.13-7 correctly named the offending file. Unfortunately, simply removing was also fatal. I created an alternative ld- linux symlink and then the upgrade could proceed. Why I say the script should take care of this! > * * * * * * > > > > The system works, except I still have the iconv problems which I did > > > > not have before. So some advice on how to fix this would be most > > > > welcome. > > > > > > Given you had a very strange system, I would suggest to run: 'apt-get > > > install --reinstall libc6'' > > > > This was done. The iconv problems remain. No man pages, no synaptic (not > > the worst) and miscelaneous problems, some harmless elsewhere. > > > > Could this iconv thing be another bug in libc6, or is there something > > else that needs be reinstalled? > > iconv files have been moved from /usr/lib/gconv to /usr/lib/i386/gconv > between version 2.13-5 and 2.13-7. If you have a system with a mix of > both versions installed, it might explain the issue. Please also check > you have no file left in /lib with 2.11 or 2.13 in their name. OK, I got rid of the 2.11 files. I, of course, did not touch the 2.13 ones. There are actually only a few of them but are locally symlinked. There would be three version of these, on /lib, lib/i386-gnu... and /lib/i686/cmov. The ones I checked a all different. Should the /lib ones be actually be removed? Should their symlinks be first changed to the i386 versions (like others in /lib ... and why is there an i686/cmov if it is not being used?) Hopefully this can be achieved without (temporarily) hosing the system. Another reason I feel the scripts should handle this stuff. All the 2.13 files are legal-dpkg items. I no longer have /usr/lib/gconv.
