Bug#306677: marked as done (libc6: /lib64 goes away on upgrade, breaks amd64)
Your message dated Thu, 28 Apr 2005 08:49:52 +0900
with message-id <811x8v3hlr.wl@omega.webmasters.gr.jp>
and subject line Bug#306677: libc6: /lib64 goes away on upgrade, breaks amd64
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 27 Apr 2005 22:37:14 +0000
>From matt@lackof.org Wed Apr 27 15:37:14 2005
Return-path: <matt@lackof.org>
Received: from colo.lackof.org [198.49.126.79]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DQv9e-0007ji-00; Wed, 27 Apr 2005 15:37:14 -0700
Received: from localhost (localhost [127.0.0.1])
by colo.lackof.org (Postfix) with ESMTP id EDBA5298058
for <submit@bugs.debian.org>; Wed, 27 Apr 2005 16:39:18 -0600 (MDT)
Received: from colo.lackof.org ([127.0.0.1])
by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 28132-04 for <submit@bugs.debian.org>;
Wed, 27 Apr 2005 16:39:18 -0600 (MDT)
Received: from cyrix.home.bogus (c-24-18-165-146.hsd1.wa.comcast.net [24.18.165.146])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "taggart.lackof.org", Issuer "ca.lackof.org" (verified OK))
by colo.lackof.org (Postfix) with ESMTP id 56C38298052
for <submit@bugs.debian.org>; Wed, 27 Apr 2005 16:39:18 -0600 (MDT)
Received: by cyrix.home.bogus (Postfix, from userid 22223)
id 3F9C51AA843; Wed, 27 Apr 2005 15:36:41 -0700 (PDT)
Received: from cyrix.home.bogus (localhost [127.0.0.1])
by cyrix.home.bogus (Postfix) with ESMTP id 3A4B92FE31
for <submit@bugs.debian.org>; Wed, 27 Apr 2005 15:36:41 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-4) with nmh-1.1
From: Matt Taggart <taggart@debian.org>
To: submit@bugs.debian.org
Subject: libc6: /lib64 goes away on upgrade, breaks amd64
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 27 Apr 2005 15:36:41 -0700
Sender: matt@lackof.org
Message-Id: <[🔎] 20050427223641.3F9C51AA843@cyrix.home.bogus>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
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 <lawrencc@debian.org> 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
taggart@debian.org
---------------------------------------
Received: (at 306677-done) by bugs.debian.org; 27 Apr 2005 23:50:01 +0000
>From gotom@debian.or.jp Wed Apr 27 16:50:01 2005
Return-path: <gotom@debian.or.jp>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DQwHx-00012u-00; Wed, 27 Apr 2005 16:49:53 -0700
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id 8C6DADEB1B; Thu, 28 Apr 2005 08:49:52 +0900 (JST)
Date: Thu, 28 Apr 2005 08:49:52 +0900
Message-ID: <811x8v3hlr.wl@omega.webmasters.gr.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Matt Taggart <taggart@debian.org>, 306677-done@bugs.debian.org
Subject: Re: Bug#306677: libc6: /lib64 goes away on upgrade, breaks amd64
In-Reply-To: <[🔎] 20050427223641.3F9C51AA843@cyrix.home.bogus>
References: <[🔎] 20050427223641.3F9C51AA843@cyrix.home.bogus>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: 306677-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
At Wed, 27 Apr 2005 15:36:41 -0700,
Matt Taggart wrote:
>
> 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)
This problem was reported a lot on debian-amd64 lists, search and read
them. Note that amd64 is not officially supported, thus severity:
critical should not be used.
Regards,
-- gotom
Reply to: