Le 21/06/2011 15:48, David Baron a écrit : >> * * * * * > >> > > > > 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.
There should not be any 2.13 file in /lib/ and /lib/i686/cmov should not exist anymore. If all these 2.13 files are legal dpkg, can you please tell us in which packages they are and in which versions? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
