Processed: Re: Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
Processing control commands: > tag -1 - pending Bug #882255 [libc6-amd64] libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25 Removed tag(s) pending. -- 882255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882255 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
control: tag -1 - pending On 2017-12-02 03:34, Mikulas Patocka wrote: > > > On Sun, 26 Nov 2017, Aurelien Jarno wrote: > > > > > You mean that even now running 'ldconfig' followed by 'ldd /bin/true' > > > > will give you > > > > libc.so.6 => /lib64/libc.so.6 > > > > instead of > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > > > ? > > > > > > Yes. > > > # ldd /bin/true > > > linux-vdso.so.1 (0x7ffc62b5a000) > > > libc.so.6 => /lib64/libc.so.6 (0x7fd870377000) > > > /lib64/ld-linux-x86-64.so.2 (0x7fd870921000) > > > > > > If I use the --inhibit-cache flag, it points to the correct location: > > > # /lib64/ld-linux-x86-64.so.2 --list --inhibit-cache /bin/true > > > linux-vdso.so.1 (0x7ffd566e4000) > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f73026c8000) > > > /lib64/ld-linux-x86-64.so.2 (0x7f7302c73000) > > > > > > Without --inhibit-cache, it points to /lib64/libc.so.6 > > > # /lib64/ld-linux-x86-64.so.2 --list /bin/true > > > linux-vdso.so.1 (0x7ffd5ad1) > > > libc.so.6 => /lib64/libc.so.6 (0x7fc566092000) > > > /lib64/ld-linux-x86-64.so.2 (0x7fc56663c000) > > > > I am still unable to reproduce this problem. On my system > > lib/x86_64-linux-gnu/ is preferred over lib64. ldconfig uses glob to to > > interpret the "*.conf" in /etc/ld.so.conf, so the files are sorted > > alphabetically and thus the zz_amd64-biarch-compat.conf should appear > > last. > > > > It would be interesting to check at the order in the cache, using > > "ldconfig -p | grep libc.so". Could you please provide that output? > > > > Thanks, > > Aurelien > > # ldconfig -p | grep libc.so > libc.so.6 (libc6,x32, ABI OS: Linux 3.4.0) => > /lib/x86_64-linux-gnux32/libc.so.6 > libc.so.6 (libc6,x86-64, ABI OS: Linux 3.2.0) => /lib64/libc.so.6 > libc.so.6 (libc6,x86-64, ABI OS: Linux 2.6.32) => > /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (libc6, ABI OS: Linux 3.2.0) => /lib32/libc.so.6 > libc.so.6 (libc6, ABI OS: Linux 2.6.32) => > /lib/i386-linux-gnu/libc.so.6 > > The problem is caused by the "ABI OS" field - the libraries in /lib64 have > higher field than the libraries in /lib/x86_64-linux-gnu/ Thanks for the details. I did all my tests with libc6:amd64 and libc6-amd64:i386, and the problem is at the end specific to libc6-amd64:x32. On the other hand i was able to reproduce the issue by changing locales, so that's at least one more possibility of this bug to get detected. > If I comment out this piece of code in the function compare in the file > glibc/elf/cache.c, the problem goes away and the linker will prefer > libraries in /lib/x86_64-linux-gnu/ and /lib/i386-linux-gnu/. > > /* > if (e2->osversion > e1->osversion) > return 1; > if (e2->osversion < e1->osversion) > return -1; > */ Some libraries other than libc.so.6 might use this mechanism, so we can't really disable it. On the other hand we can ensure that all libc for a given architecture and version are built for the same kernel version. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Sun, 26 Nov 2017, Aurelien Jarno wrote: > > > You mean that even now running 'ldconfig' followed by 'ldd /bin/true' > > > will give you > > > libc.so.6 => /lib64/libc.so.6 > > > instead of > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > > ? > > > > Yes. > > # ldd /bin/true > > linux-vdso.so.1 (0x7ffc62b5a000) > > libc.so.6 => /lib64/libc.so.6 (0x7fd870377000) > > /lib64/ld-linux-x86-64.so.2 (0x7fd870921000) > > > > If I use the --inhibit-cache flag, it points to the correct location: > > # /lib64/ld-linux-x86-64.so.2 --list --inhibit-cache /bin/true > > linux-vdso.so.1 (0x7ffd566e4000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f73026c8000) > > /lib64/ld-linux-x86-64.so.2 (0x7f7302c73000) > > > > Without --inhibit-cache, it points to /lib64/libc.so.6 > > # /lib64/ld-linux-x86-64.so.2 --list /bin/true > > linux-vdso.so.1 (0x7ffd5ad1) > > libc.so.6 => /lib64/libc.so.6 (0x7fc566092000) > > /lib64/ld-linux-x86-64.so.2 (0x7fc56663c000) > > I am still unable to reproduce this problem. On my system > lib/x86_64-linux-gnu/ is preferred over lib64. ldconfig uses glob to to > interpret the "*.conf" in /etc/ld.so.conf, so the files are sorted > alphabetically and thus the zz_amd64-biarch-compat.conf should appear > last. > > It would be interesting to check at the order in the cache, using > "ldconfig -p | grep libc.so". Could you please provide that output? > > Thanks, > Aurelien # ldconfig -p | grep libc.so libc.so.6 (libc6,x32, ABI OS: Linux 3.4.0) => /lib/x86_64-linux-gnux32/libc.so.6 libc.so.6 (libc6,x86-64, ABI OS: Linux 3.2.0) => /lib64/libc.so.6 libc.so.6 (libc6,x86-64, ABI OS: Linux 2.6.32) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (libc6, ABI OS: Linux 3.2.0) => /lib32/libc.so.6 libc.so.6 (libc6, ABI OS: Linux 2.6.32) => /lib/i386-linux-gnu/libc.so.6 The problem is caused by the "ABI OS" field - the libraries in /lib64 have higher field than the libraries in /lib/x86_64-linux-gnu/ If I comment out this piece of code in the function compare in the file glibc/elf/cache.c, the problem goes away and the linker will prefer libraries in /lib/x86_64-linux-gnu/ and /lib/i386-linux-gnu/. /* if (e2->osversion > e1->osversion) return 1; if (e2->osversion < e1->osversion) return -1; */ Mikulas
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-26 09:21, Bastian Blank wrote: > On Sun, Nov 26, 2017 at 09:13:52AM +0100, Bastian Blank wrote: > > It seems that ldconfig does not force the collation to a value that > > would make it use the claimed sorting. This is indeed correct, that said it's not true for the locale of the reporter, ie cz_CZ.utf8, so I am afraid there is another bug there, probably related though. > ldconfig: > -> setlocale (LC_ALL, "") This is done for ldconfig to be able to display localized messages. > -> glob() >-> qsort(strcoll-equiv) > > Other occurances of similar bugs: https://bugs.debian.org/600310 I see two way of fixing this issue: - make sure the directories are sorted in a locale independent way - update debian/patches/any/local-ldconfig-multiarch.diff to add standard search paths before the configured ones. While this is definitely a bug, I still believe that we should not allow the installation of libc6:amd64 and libc6-amd64:i386 together and that gcc should be able to use the multiarch library as an alternative to the multilib one, so that users are not forced to install two almost identical libc on their systems, with the consequences we see. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Sun, Nov 26, 2017 at 09:13:52AM +0100, Bastian Blank wrote: > It seems that ldconfig does not force the collation to a value that > would make it use the claimed sorting. ldconfig: -> setlocale (LC_ALL, "") -> glob() -> qsort(strcoll-equiv) Other occurances of similar bugs: https://bugs.debian.org/600310 Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Sun, Nov 26, 2017 at 01:03:58AM +0100, Aurelien Jarno wrote: > I am still unable to reproduce this problem. On my system > lib/x86_64-linux-gnu/ is preferred over lib64. ldconfig uses glob to to > interpret the "*.conf" in /etc/ld.so.conf, so the files are sorted > alphabetically and thus the zz_amd64-biarch-compat.conf should appear > last. There exists locales where this claim is false: | $ LC_COLLATE=et_EE.UTF-8 ls -al /etc/ld.so.conf.d | total 20 | drwxr-xr-x 2 root root 4096 Nov 26 08:07 . | drwxr-xr-x 82 root root 4096 Nov 21 09:34 .. | -rw-r--r-- 1 root root 38 Jun 26 2016 fakeroot-x86_64-linux-gnu.conf | -rw-r--r-- 1 root root 44 Mär 20 2016 libc.conf | -rw-r- 1 root root0 Nov 26 08:07 zz.conf | -rw-r--r-- 1 root root 68 Jul 26 2016 x86_64-linux-gnu.conf It seems that ldconfig does not force the collation to a value that would make it use the claimed sorting. Bastian -- Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-21 01:43, Mikulas Patocka wrote: > > > On Tue, 21 Nov 2017, Aurelien Jarno wrote: > > > On 2017-11-21 01:01, Mikulas Patocka wrote: > > > > > > > > > On Tue, 21 Nov 2017, Aurelien Jarno wrote: > > > > > > > On 2017-11-21 00:12, Mikulas Patocka wrote: > > > > > > > > > > > > > > > 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. > > > > > > > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but > > > > mixed it when typing the mail. > > > > > > > > > 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. > > > > > > > > > > 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 > > > > >
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Tue, 21 Nov 2017, Aurelien Jarno wrote: > On 2017-11-21 01:01, Mikulas Patocka wrote: > > > > > > On Tue, 21 Nov 2017, Aurelien Jarno wrote: > > > > > On 2017-11-21 00:12, Mikulas Patocka wrote: > > > > > > > > > > > > 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. > > > > > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but > > > mixed it when typing the mail. > > > > > > > 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. > > > > > > > > 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/. > > > > > > Those files are installed with the zz_ prefix to make sure they are > > >
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-21 01:01, Mikulas Patocka wrote: > > > On Tue, 21 Nov 2017, Aurelien Jarno wrote: > > > On 2017-11-21 00:12, Mikulas Patocka wrote: > > > > > > > > > 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. > > > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but > > mixed it when typing the mail. > > > > > 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. > > > > > > 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/. > > > > Those files are installed with the zz_ prefix to make sure they are > > included last, and therefore after x86_64-linux-gnu.conf. It seems to > > be missing on your system and is probably the root of your problem. This > > file is installed by libc6:amd64. > > > > Aurelien > > I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains > # Multiarch support > /lib/x86_64-linux-gnu >
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Tue, 21 Nov 2017, Aurelien Jarno wrote: > On 2017-11-21 00:15, Mikulas Patocka wrote: > > > > > > On Mon, 20 Nov 2017, Aurelien Jarno wrote: > > > > > On 2017-11-20 21:58, Mikulas Patocka wrote: > > > > > > > > > > > > On Mon, 20 Nov 2017, Samuel Thibault wrote: > > > > > > > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > > > > > 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. > > > > > > > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not > > > > > new, I > > > > > tried to do it in the past, just to see, with the same kind of effect > > > > > as > > > > > you had. > > > > > > > > > > The question is rather how that got pulled at all. What package thinks > > > > > it's a good idea to pull libc6-amd64? Apart from libc64* packages > > > > > (which should normally not get pulled either), I can see uc-echo which > > > > > should rather use foreign dependencies, and :i386 multilib packages > > > > > which don't really make sense to install either. > > > > > > > > > > I don't remember whether it was tried to make libc6-amd64:i386 > > > > > conflict > > > > > with libc6:amd64 (and vice-versa for i386) to make sure that this > > > > > doesn't happen by misfortune? > > > > > > > > > > Samuel > > > > > > > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, > > > > lib64asan3, > > > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, > > > > lib64itm1, > > > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64. > > > > > > > > If you install gcc-7-multilib for non-default architecture (i386 or > > > > x32), > > > > it will inevitably pull libc6-amd64. > > > > > > What's the point of doing that, as opposed for example building with > > > -m32 or mx32? > > > > The native x32 gcc binary is about 10% faster than the amd64 binary. > > In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32, > which won't pull libc6-amd64:x32. But then, it won't be able to build i386 and amd64 binaries. Mikulas > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net >
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Tue, 21 Nov 2017, Aurelien Jarno wrote: > On 2017-11-21 00:12, Mikulas Patocka wrote: > > > > > > 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. > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but > mixed it when typing the mail. > > > 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. > > > > 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/. > > Those files are installed with the zz_ prefix to make sure they are > included last, and therefore after x86_64-linux-gnu.conf. It seems to > be missing on your system and is probably the root of your problem. This > file is installed by libc6:amd64. > > Aurelien I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu But nonetheless, the linker prefers libc from /lib64. I have these files in /etc/ld.so.conf.d: i386-linux-gnu.conf:# Multiarch support i386-linux-gnu.conf:/lib/i386-linux-gnu i386-linux-gnu.conf:/usr/lib/i386-linux-gnu i386-linux-gnu.conf:/lib/i686-linux-gnu i386-linux-gnu.conf:/usr/lib/i686-linux-gnu
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-21 00:12, Mikulas Patocka wrote: > > > 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. Yes, sorry about that, I really did the test with libc6-amd64:i386, but mixed it when typing the mail. > 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. > > 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/. Those files are installed with the zz_ prefix to make sure they are included last, and therefore after x86_64-linux-gnu.conf. It seems to be missing on your system and is probably the root of your problem. This file is installed by libc6:amd64. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-21 00:15, Mikulas Patocka wrote: > > > On Mon, 20 Nov 2017, Aurelien Jarno wrote: > > > On 2017-11-20 21:58, Mikulas Patocka wrote: > > > > > > > > > On Mon, 20 Nov 2017, Samuel Thibault wrote: > > > > > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > > > > 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. > > > > > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I > > > > tried to do it in the past, just to see, with the same kind of effect as > > > > you had. > > > > > > > > The question is rather how that got pulled at all. What package thinks > > > > it's a good idea to pull libc6-amd64? Apart from libc64* packages > > > > (which should normally not get pulled either), I can see uc-echo which > > > > should rather use foreign dependencies, and :i386 multilib packages > > > > which don't really make sense to install either. > > > > > > > > I don't remember whether it was tried to make libc6-amd64:i386 conflict > > > > with libc6:amd64 (and vice-versa for i386) to make sure that this > > > > doesn't happen by misfortune? > > > > > > > > Samuel > > > > > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, > > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, > > > lib64itm1, > > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64. > > > > > > If you install gcc-7-multilib for non-default architecture (i386 or x32), > > > it will inevitably pull libc6-amd64. > > > > What's the point of doing that, as opposed for example building with > > -m32 or mx32? > > The native x32 gcc binary is about 10% faster than the amd64 binary. In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32, which won't pull libc6-amd64:x32. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
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 21:58, Mikulas Patocka wrote: > > > > > > On Mon, 20 Nov 2017, Samuel Thibault wrote: > > > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > > > 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. > > > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I > > > tried to do it in the past, just to see, with the same kind of effect as > > > you had. > > > > > > The question is rather how that got pulled at all. What package thinks > > > it's a good idea to pull libc6-amd64? Apart from libc64* packages > > > (which should normally not get pulled either), I can see uc-echo which > > > should rather use foreign dependencies, and :i386 multilib packages > > > which don't really make sense to install either. > > > > > > I don't remember whether it was tried to make libc6-amd64:i386 conflict > > > with libc6:amd64 (and vice-versa for i386) to make sure that this > > > doesn't happen by misfortune? > > > > > > Samuel > > > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64. > > > > If you install gcc-7-multilib for non-default architecture (i386 or x32), > > it will inevitably pull libc6-amd64. > > What's the point of doing that, as opposed for example building with > -m32 or mx32? The native x32 gcc binary is about 10% faster than the amd64 binary. > > If we removed libc6-amd64 at all, it would cause problems building amd64 > > packages on i386 system. We could make those lib64* packages dependent on > > libc6:amd64 instead, but that would break if the user has i386 > > installation and he doesn't have amd64 foreign architecture set up. > > > > It would be best to set it up so that libc6-amd64 doesn't install any > > files only if libc6:amd64 is present. Could it be done with the deb > > format? > > It's not something possible, and it's even more complicated than that. > The current ugly way the multiarch + multilib is done, uses a different > libc for linking and executing. So you definitely need to install both > if you want to be able to build and execute code. > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net Mikulas
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 > aurel...@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
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
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 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 aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-20 21:58, Mikulas Patocka wrote: > > > On Mon, 20 Nov 2017, Samuel Thibault wrote: > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > > 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. > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I > > tried to do it in the past, just to see, with the same kind of effect as > > you had. > > > > The question is rather how that got pulled at all. What package thinks > > it's a good idea to pull libc6-amd64? Apart from libc64* packages > > (which should normally not get pulled either), I can see uc-echo which > > should rather use foreign dependencies, and :i386 multilib packages > > which don't really make sense to install either. > > > > I don't remember whether it was tried to make libc6-amd64:i386 conflict > > with libc6:amd64 (and vice-versa for i386) to make sure that this > > doesn't happen by misfortune? > > > > Samuel > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64. > > If you install gcc-7-multilib for non-default architecture (i386 or x32), > it will inevitably pull libc6-amd64. What's the point of doing that, as opposed for example building with -m32 or mx32? > If we removed libc6-amd64 at all, it would cause problems building amd64 > packages on i386 system. We could make those lib64* packages dependent on > libc6:amd64 instead, but that would break if the user has i386 > installation and he doesn't have amd64 foreign architecture set up. > > It would be best to set it up so that libc6-amd64 doesn't install any > files only if libc6:amd64 is present. Could it be done with the deb > format? It's not something possible, and it's even more complicated than that. The current ugly way the multiarch + multilib is done, uses a different libc for linking and executing. So you definitely need to install both if you want to be able to build and execute code. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Mon, 20 Nov 2017, Samuel Thibault wrote: > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > 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. > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I > tried to do it in the past, just to see, with the same kind of effect as > you had. > > The question is rather how that got pulled at all. What package thinks > it's a good idea to pull libc6-amd64? Apart from libc64* packages > (which should normally not get pulled either), I can see uc-echo which > should rather use foreign dependencies, and :i386 multilib packages > which don't really make sense to install either. > > I don't remember whether it was tried to make libc6-amd64:i386 conflict > with libc6:amd64 (and vice-versa for i386) to make sure that this > doesn't happen by misfortune? > > Samuel libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64. If you install gcc-7-multilib for non-default architecture (i386 or x32), it will inevitably pull libc6-amd64. If we removed libc6-amd64 at all, it would cause problems building amd64 packages on i386 system. We could make those lib64* packages dependent on libc6:amd64 instead, but that would break if the user has i386 installation and he doesn't have amd64 foreign architecture set up. It would be best to set it up so that libc6-amd64 doesn't install any files only if libc6:amd64 is present. Could it be done with the deb format? Mikulas
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On 2017-11-20 20:47, Samuel Thibault wrote: > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > > 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. > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I > tried to do it in the past, just to see, with the same kind of effect as > you had. > > The question is rather how that got pulled at all. What package thinks > it's a good idea to pull libc6-amd64? Apart from libc64* packages > (which should normally not get pulled either), I can see uc-echo which > should rather use foreign dependencies, and :i386 multilib packages > which don't really make sense to install either. > > I don't remember whether it was tried to make libc6-amd64:i386 conflict > with libc6:amd64 (and vice-versa for i386) to make sure that this > doesn't happen by misfortune? Arch-qualified conflicts are not supported. What you can do is make libc6-amd64 and libc6:amd64 not coinstallable (by changing the Replaces into a Conflicts). Maybe it's time to do it and let GCC enjoy multiarch + multilib pain. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote: > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide > 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. The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I tried to do it in the past, just to see, with the same kind of effect as you had. The question is rather how that got pulled at all. What package thinks it's a good idea to pull libc6-amd64? Apart from libc64* packages (which should normally not get pulled either), I can see uc-echo which should rather use foreign dependencies, and :i386 multilib packages which don't really make sense to install either. I don't remember whether it was tried to make libc6-amd64:i386 conflict with libc6:amd64 (and vice-versa for i386) to make sure that this doesn't happen by misfortune? Samuel
Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
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 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. 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. The system can be fixed if we mount it from another machine and remove the libc files from /lib64 directory - the upgrade can then proceed and install correct libc in /lib/x86_64-linux-gnu/. The libc package should be fixed, so that if we have mismatching libc version in /lib64 and in /lib/x86_64-linux-gnu/, it shouldn't crash, because such mismatch happens temporarily during upgrade. -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 4.14.0 (SMP w/12 CPU cores; PREEMPT) Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8), LANGUAGE=cs_CZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libc6-amd64 depends on: ii libc6 2.25-1 libc6-amd64 recommends no packages. libc6-amd64 suggests no packages. -- no debconf information
