Package: libc6 Version: 2.11.2-2 Severity: critical Justification: breaks the whole system (repeatedly, in a timebomb manner)
Hi, beginning of August my intention was to upgrade a system (AMD64 i386 stable; libc6-i686 installed additionally) to KDE 4.4.x. I chose to do this by temporarily switching to testing repository. All went more or less fine, except for suddenly ending up with all shell binaries segfaulting. A reboot resulted in /sbin/init dying with a nice kernel OOPS. Full stop. Found #586241 (somewhat related issue), which recommended dpkg-deb:ing over the libc6 / libc6-i686 libraries to restore the system. Worked. Hurray. Ultimately, I managed to figure out that the problem is caused by an old prelink version which doesn't seem to get along at all with new(er?) libc6 version. See also the initial warning report, "prelink-2007* and libc6-2.11* don't mix.": http://lists.debian.org/debian-user/2010/06/msg02063.html But, right after the upgrade, I hadn't realized the prelink issue yet. Note that, rather worse, prelink is cron-registered (cron.daily), providing a nice time bomb by rendering a system fully unusable again the next day. IOW, you copy over pristine libc6 libs, everything boots fine again, you think it's all fixed ("must have been some stupid libc6 update issue"), and one day later it's all broken again right when one is unavailable to get this fixed (yup, you're staring at the person that this happened to). The issue occurred with the old prelink 0.0.20090311-1 package, updating to 0.0.20090925-1 fixed everything, no more prelink breakage. Contrary to the conclusion in the rather helpful warning given by Boyd Stephen Smith Jr. above (well, rather helpful if I actually had managed to find it in advance...), I believe that something rather easy can and should actually be done about it, to prevent other people from falling into the same very irritating trap: provide a Conflicts: prelink (<= 0.0.20090311-1) package line or some such, which should hopefully be the proper means to get this avoided. I'm not sure of more precise version values to be provided here, though, I only know of 0.0.20090311-1 behaviour. libc6 specifics: 2010-07-31 19:11:57 upgrade libc6 2.9-25 2.11.2-2 Fallout of this issue really was not nice at all for me personally (dead semi-production box for > 2 weeks, due to the cron timebomb complication), thus myself I'd definitely want to see a protection applied, despite being a __severe__ problem for a branch-hopping minority(?) only. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org