Bug#953562: libcrypt1 should ship file in /usr, breaks is useless

Julian Andres Klode

unread,

Mar 10, 2020, 1:00:03 PM3/10/20

to

Package: libcrypt1
Severity: serious

libcrypt1 currently ships the file in /usr/lib, whereas libc6
shipped it in /lib, meaning that the Replaces relationship to
libc6 is not doing anything on usrmerged systems.

Please move it back to /lib until after bullseye, so that
the Replaces actually work, and ownership of libcrypt1 is
properly transferred from libc6 to libcrypt1.

It likely works out fine in practice in most cases, but
let's be safe, k?

-- System Information:
Debian Release: bullseye/sid
APT prefers focal
APT policy: (991, 'focal'), (500, 'focal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-18-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcrypt1 depends on:
ii libc6 2.30-0ubuntu3

libcrypt1 recommends no packages.

libcrypt1 suggests no packages.

-- no debconf information

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

Julian Andres Klode

unread,

Mar 10, 2020, 1:20:03 PM3/10/20

to

On Tue, Mar 10, 2020 at 05:58:04PM +0100, Marco d'Itri wrote:
> On Mar 10, Julian Andres Klode <j...@debian.org> wrote:
>
> > It likely works out fine in practice in most cases, but
> > let's be safe, k?

> Do you care enough to test a patch?

We're going to roll out the change in Ubuntu shortly, so there'll
be a ton of testing going on involving libc6 + libcrypt1 upgrades
when the autopkgtests run.

But yes, we should also check the other direction in Debian I guess
where we already have libc6 + libcrypt1 installed and then change
the path, though I'm not sure what could go bad there.

signature.asc

John Paul Adrian Glaubitz

unread,

Mar 14, 2020, 10:40:03 AM3/14/20

to

Package: libcrypt1
Version: 1:4.4.15-1
Followup-For: Bug #953562
User: debia...@lists.debian.org
Usertags: ia64

Hello!

This actually causes issues on ia64 now:

Setting up libc6.1:ia64 (2.30-2) ...
/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
dpkg: error processing package libc6.1:ia64 (--configure):
installed libc6.1:ia64 package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
libc6.1:ia64
E: Sub-process /usr/bin/dpkg returned an error code (1)
apt-get failed.
E: Package installation failed

So it's not just a theoretical issue.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Timo Kluck

unread,

Mar 15, 2020, 7:50:03 AM3/15/20

to

I'd like to report that this is the possible cause of my system being unbootable at the moment.

I run Ubuntu Focal on a Dell laptop and run regular `dist-upgrade`s. The latest one seems to have triggered the corner case described above.

Booting fails to get to my desktop. Ubuntu's recovery mode gets to the menu where "dpkg" and "root shell" are options. Choosing the former, I see log messages about lib6 configuration failing because perl cannot load because of libcrypt.so. This is why I suspect this bug as the root cause.

The root shell also fails to start but the logs disappear too quickly.

I'll attempt to recover with a live cd and can post updates here if that's useful.

Thank you!

Timo Kluck

unread,

Mar 15, 2020, 10:00:03 AM3/15/20

to

>> I'll attempt to recover with a live cd and can post updates here if that's
>> useful.

> chroot and run ldconfig, for a start.
Thanks for the suggestion. I ended up doing something similar in
parallel (apologies for ubuntu-specific instructions):

1. boot into the live cd (I used ubuntu 18.04)
2. mount the hard drive (the live cd's graphical session also supports
encrypted drives)
3. copy the live cd's libcrypt.so.1 to the mounted hard drive
4. boot into normal (ie. not live cd) recovery mode and select the
dpkg option. The configure step now completes without issue
5. boot normally

I don't think there's any remaining artefacts: dpkg also replaced the
temporary libcrypt.so.1 with the symlink that it's supposed to be.

Marco d'Itri

unread,

Mar 15, 2020, 10:20:04 AM3/15/20

to

On Mar 15, Timo Kluck <tkl...@infty.nl> wrote:

> Thanks for the suggestion. I ended up doing something similar in
> parallel (apologies for ubuntu-specific instructions):

Then this is not interesting.

--
ciao,
Marco

signature.asc

Paul Gevers

unread,

Apr 14, 2021, 3:00:04 PM4/14/21

to

Hi Ivo, Marco,

On 06-04-2021 22:10, Ivo De Decker wrote:
> I ran a number of (partial and full) upgrade tests, and they all seem to work
> fine. In all cases, libcrypt1 is installed before libc6, and there is no
> intermediate situations where libcrypt.so.1 is missing.

The patch looks sensible after reading the discussion in these bugs. Can
we have an upload soon to have exposure?

Paul

OpenPGP_signature

Marco d'Itri

unread,

Apr 15, 2021, 8:40:03 AM4/15/21

to

On Apr 14, Paul Gevers <elb...@debian.org> wrote:

> The patch looks sensible after reading the discussion in these bugs. Can
> we have an upload soon to have exposure?

Unless there are any objections I will do a libxcrypt upload in a couple
of days.

I think that I can leave the udeb library in /usr/lib/.

--
ciao,
Marco

signature.asc

Niko Tyni

unread,

Apr 15, 2021, 2:00:03 PM4/15/21

to

Hi, thanks for your work on this and sorry I'm chiming in so late.

I'm concerned that AFAICS no change in src:libxcrypt can make sure that
the new libc6 is never unpacked before libcrypt1.

(buster-amd64)# dpkg --unpack libc6_2.31-11_amd64.deb
(Reading database ... 12224 files and directories currently installed.)
Preparing to unpack libc6_2.31-11_amd64.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Unpacking libc6:amd64 (2.31-11) over (2.28-10) ...
(buster-amd64)# perl
perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

It may well be enough to make this improbable enough in practice. Ivo's
testing certainly seems to indicate so. It still makes me a bit uneasy.

I'm happy to be proved wrong of course. Do the Important or Protected
fields in the patch affect apt's behaviour in this, for instance?

The solution Aurelien mentioned of copying the old libcrypt in
libc6.preinst and cleaning up in libc6.postinst would eliminate this
failure mode totally. But I can see it's not very desirable and may be
hard to make robust.

Just wanted to bring this up explicitly. Not objecting if we deem the
risk of remaining corner case issues small enough that it's worth taking.
--
Niko