Bug#630608: [bash] Everything Segfaults After lib6 -7 Upgrade
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: