Hi, Could this bug be caused by a corrupt aux-cache[1] (possibly, in addition to a corrupt ld.so.cache)?
A bit of google searching suggests that a broken aux-cache can cause ldconfig to seg. fault. With the ld.so.cache itself being corrupt (or sufficiently outdated?), both ldconfig and most other binaries would simply "just seg. fault" fitting the symptoms pretty well so far. It partly also fits with the removal of libjasper1, as the removed library would force ldconfig to *not* use its cache for said library. Though I cannot explain why it seems like stat itself seg. faults. Assuming my hypothesis is correct, a broken system could be restored by running[2]: $ ldconfig.real --ignore-aux-cache Failling that: $ > /var/cache/ldconfig/aux-cache $ ldconfig.real Maybe take a copy of the aux-cache before doing the "restore" command(s). This way we should be able to "re-break" the system by re-instating the old aux-cache (and possibly breaking the ld.so.cache). Thanks, ~Niels [1] /var/cache/ldconfig/aux-cache [2] Using ldconfig.real in case /bin/sh got borked by the ld.so.cache as well. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e44e19.7040...@thykier.net