Dennis Wicks wrote: > Just to clarify, the "bad" system is only "bad" because whein I was > installing an update, for Open Office if memory serves, aptitude > crashed and left "something" in an unusable state that causes > segmentation faults and relocation errors whenever I try to run > anything "new". Yes. But a couple of points. One is that OpenOffice.org has a very large cone of dependencies behind it. The problem could have been one of the libraries pulled in because of that cone. The top of the cone might be simply OpenOffice.org and very small but the bottom of the cone might be very large! > That is, the things that were running when aptitude crashed are > still running. Like Thunderbird, Iceweasel, a couple x-window > terminal sessions, and Opera. Anything I try to start now fails to > do so for the aforementioned reasons. But along the way it was suggested that you use a chroot and use the dpkg --root option and other things that required you shutting the system down and mounting the disk on another system. So with that in mind there won't be any process that are still running. All of them would be new processes.. > As far as I can tell the disk is physically OK. But I will check it > out, just in case. I'll also check the lock file, etc. I haven't seen anything that makes me think the disk has failed. Probably okay. If everything you run is segfaulting the the problem is probably in one of the shared libraries that has a large cone of dependents. But the number of really critical shared libraries is fairly small. $ ldd -d -r /usr/bin/apt-get linux-vdso.so.1 => (0x00007fff787ff000) libapt-pkg.so.4.10 => /usr/lib/libapt-pkg.so.4.10 (0x00007f314355c000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3143358000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3143054000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3142dd2000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3142bbb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3142837000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3142633000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f314241b000) /lib64/ld-linux-x86-64.so.2 (0x00007f3143a93000) That is a fairly manageable number of libraries. I would check the md5sum of those against the known good list. Bob
Attachment:
signature.asc
Description: Digital signature