[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25




On Mon, 20 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-20 19:13, Mikulas Patocka wrote:
> > Package: libc6-amd64
> > Version: 2.25-1
> > Severity: critical
> > Justification: breaks the whole system
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate ***
> > 
> >    * What led up to the situation?
> > 
> > I have a x86-64 system with i386 and x32 foreign architectures (because I
> > need to develop software for i386 and x32 architectures).
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> > 
> > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > 
> >    * What was the outcome of this action?
> > 
> > Halfway through apt upgrade it failed and I ended up with unusable system where
> > large number of binaries were segfauting on startup without doign anything.
> > 
> >    * What outcome did you expect instead?
> > 
> > The upgrade to libc-2.25 should work.
> > 
> > 
> > The reason for the catastrophic failure is this:
> > 
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> 
> I guess you mean you have installed one of the two, not both.
> 
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> Just to be clear, as said in my other email, this *is* technically
> needed as gcc-multilib is not able to make use of the libc in
> /lib/x86_64-linux-gnu.
> 
> > apt makes sure that all libc packages are upgraded at once to the same
> > version. However, during the upgrade process, the package
> > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > temporarily have two libcs with different versions on the system, and this
> > mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> > upgrade doesn't proceed and it doesn't install the correct libc version in
> > /lib/x86_64-linux-gnu/.
> > 
> > The result is unusable system.
> 
> I have done some tests, and while I confirm that libc6-i386:amd64 is

The problem is with libc6-amd64:i386 or libc6-amd64:x32.
Not libc6-i386:amd64.

I.e. use amd64 Debian Sid base installation, add foreign architectures 
i386 and x32 and use this /etc/apt/sources.list:

deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib non-free
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main

> unpacked much before libc6:amd64, it doesn't cause any issue here.
> Indeed the search path in ld.so is to give higher priority to
> /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> libc6:amd64 in version 2.24 (using force-all), while keeping
> libc6-amd64:i386 in version 2.25.
> 
> The only way to change the priority of the two path is using a
> non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> this directory.
> 
> -- 
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                 http://www.aurel32.net

On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
containing:

# Legacy biarch compatibility support
/lib64
/usr/lib64

and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:

# Legacy biarch compatibility support
/lib32
/usr/lib32

These files are created by the packages libc6-i386:x32 and 
libc6-amd64:x32. They cause that /lib64 is preferred to 
/lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
linker will prefer /lib/x86_64-linux-gnu/.

Mikulas


Reply to: