|
On Tuesday 19 Sivan 5771 01:21:46 Aurelien Jarno wrote: > On Mon, Jun 20, 2011 at 10:30:45PM +0300, David Baron wrote: > > On Monday 18 Sivan 5771 21:16:28 David Baron wrote: > > > On Monday 18 Sivan 5771 20:18:42 David Baron wrote: > > > > I was looking at the content of my /lib variations. Very interesting. > > > > > > > > The testing one I am using now las libc.so.6 -> libc-2.13.so dated > > > > May 12. The "sid" one I copied from the segfaulting /lib has > > > > libc.so.6 -> libc-2.11.2.so dated JUNE! > > > > > > > > Something is amiss here, huh? > > > > All the 2.13 files, symlinks are from May > > > > All the 2.11.2 files, symlinks are from June (which is when I > > > > downgraded). Question would be why the sid files point to older > > > > libraries after upgrading in June? > > > > > > > > What library path is used for init which does work? > > > > There is a libc.so in /usr/lib/i386-linux-gnu of the same June date. > > > > > > 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. > > > 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. > > 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. > > i386 target and it took that. I re-upgraded all the X and GCC stuff that > > I had downgraded. > > > > So the problem is in the libc6 installation scripts. > > If we consider that the installation scripts should fix files that > should not have been there at the first place. > Considering the number of people who have had problems, especially upgrading from 2.11 to 2.13, I think is should be handled by the script. I am not just talking about "my" bug. Try a google. > > 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? |