Package: libc6 Version: 2.3.2.ds1-21 Severity: critical Justification: causes amd64 systems to become completely unusable upon dist-upgrade
A person I know ran into a critical bug on amd64 today. He was apt-get dist-upgrading his system things broke horribly, ... Get:171 http://debian-amd64.alioth.debian.org sid/main telnet-ssl 0.17.24+0.1-7.1 [88.1kB] Fetched 105MB in 2m42s (649kB/s) Preconfiguring packages ... (Reading database ... 24453 files and directories currently installed.) Preparing to replace base-files 3.1.1.0.0.1.pure64 (using .../base-files_3.1.2-0.0.1_amd64.deb) ... Unpacking replacement base-files ... dpkg (subprocess): failed to exec rm for cleanup: No such file or directory dpkg: error while cleaning up: subprocess rm cleanup returned error exit status 2 Could not exec dpkg! E: Sub-process /usr/bin/dpkg returned an error code (100) and after that the existing shell was still working, but nothing would run, always complaining "no such file or directory". dannf was able to figure out that the /lib64 -> /lib symlink got deleted. All debian binary-amd64 binaries have /lib64 in their hardcoded PI like this, $ strings /bin/ls |head -1 /lib64/ld-linux-x86-64.so.2 So that's why everything was complaining "no such file or directory". We were able to replace the symlink using the PI directly, /lib/ld-linux-x86-64.so.2 ln -s /lib64 /lib and then all things were back to normal. I started looking around for how this could have happened. Both libc6 and lsb-core provide /lib64. Looking at the lsb-core changelog, lsb (2.0-2) experimental; urgency=low ... * Include /lib64 in the AMD64 package rather than running mkdir in the postinst. ... -- Chris Lawrence <[EMAIL PROTECTED]> Mon, 20 Sep 2004 21:38:36 -0500 So lsb-core's old mkdir method was ensuring that that symlink got created and stuck around. Once the package moved to delivering it as a normal file it can be missing during an upgrade. So.... I'm speculating that in this case all the packages that provide /lib64 were providing it as a package file and being upgraded in the same pass. This caused /lib64 to go away and everything to blow up. Does that sound correct? I propose that libc6 is the correct package to ensure that /lib64 gets created and exists across upgrades. Even if we do move to multiarch, /lib64 is going to need to stick around for a very long time. If at some point in the distant future we can finally get rid of it, whatever libc package we're using at that point can check for it and remove it in a package script. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
