Dear Maintainer,

This is also meant as a friendly heads up, as #1065135.

I don't know if this happened due to specifities of my system, which has been
upgraded several times, since more than 10 years.
It left my system without a working sudo to fix it, so it was critical for me.
I leave it to maintainers to adjust severity, if it also happens to other
users.
(And also I was fortunate to find a solution, that I include here in case it
could be useful to others.)

   * What led up to the situation?

sudo apt full-upgrade

   * What was the outcome of this action?

Extracts from apt full-upgrade output:
"Les paquets suivants seront ENLEVÉS :" (Following packages will be REMOVED)
[…] libssl3 libssl3:i386 […]

"Les NOUVEAUX paquets suivants seront installés :" (NEW packages will be
installed)
[…] libssl3t64 libssl3t64:i386 […]

(which looked ok — and most other libraries were actually replaced by their t64
substitutes)

But then:
[…]
(Lecture de la base de données... 614199 fichiers et répertoires déjà
installés.)
Suppression de libssl3:i386 (3.1.5-1) ...
dpkg: libssl3:amd64 : problèmes de dépendance, mais suppression comme demandé :
 wpasupplicant dépend de libssl3 (>= 3.0.0).
 w3m dépend de libssl3 (>= 3.0.0).
 virtuoso-opensource-7-common dépend de libssl3 (>= 3.0.0).
 transmission-gtk dépend de libssl3 (>= 3.0.0).
 tnftp dépend de libssl3 (>= 3.0.0).
 systemd-container dépend de libssl3 (>= 3.0.0).
 systemd dépend de libssl3 (>= 3.0.0).
 sudo dépend de libssl3 (>= 3.0.0).
 socat dépend de libssl3 (>= 3.0.0).
 rsync dépend de libssl3 (>= 3.0.0).
 python3-cryptography dépend de libssl3 (>= 3.0.0).
 ppp dépend de libssl3 (>= 3.0.0).
 postgresql-client-16 dépend de libssl3 (>= 3.0.0).
 postgresql-client-15 dépend de libssl3 (>= 3.0.0).
 postgresql-client-14 dépend de libssl3 (>= 3.0.0).
 postgresql-16 dépend de libssl3 (>= 3.0.0).
 postgresql-15 dépend de libssl3 (>= 3.0.0).
 postgresql-14 dépend de libssl3 (>= 3.0.0).
 perl-openssl-defaults:amd64 dépend de libssl3 (>= 3.0.0).
 openvpn dépend de libssl3 (>= 3.0.0).
 openssl dépend de libssl3 (>= 3.0.9).
 openssh-server dépend de libssl3 (>= 3.0.0).
 openssh-client dépend de libssl3 (>= 3.0.0).
 nmap dépend de libssl3 (>= 3.0.0).
 mumble dépend de libssl3 (>= 3.0.0).
 linux-kbuild-6.6.15 dépend de libssl3 (>= 3.0.0).
 linux-kbuild-6.6.13 dépend de libssl3 (>= 3.0.0).
 libzip4:amd64 dépend de libssl3 (>= 3.0.0).
 libxmlsec1-openssl:amd64 dépend de libssl3 (>= 3.0.0).
 libwinpr2-2:amd64 dépend de libssl3 (>= 3.0.0).
 libvirtodbc0 dépend de libssl3 (>= 3.0.0).
 libtss2-esys-3.0.2-0:amd64 dépend de libssl3 (>= 3.0.0).
 libsystemd-shared:amd64 dépend de libssl3 (>= 3.0.0).
 libssl-dev:amd64 dépend de libssl3 (= 3.1.5-1).
 libssh-4:amd64 dépend de libssl3 (>= 3.0.0).
 libspice-client-glib-2.0-8:amd64 dépend de libssl3 (>= 3.0.0).
 libshout3:amd64 dépend de libssl3 (>= 3.0.0).
 libruby3.1:amd64 dépend de libssl3 (>= 3.0.0).
 libruby3.0:amd64 dépend de libssl3 (>= 3.0.0).
 librabbitmq4:amd64 dépend de libssl3 (>= 3.0.0).
 libqt6network6:amd64 dépend de libssl3.
 libqt5network5:amd64 dépend de libssl3.
 libqca-qt5-2-plugins:amd64 dépend de libssl3 (>= 3.0.0).
 libpython3.12-minimal:amd64 dépend de libssl3 (>= 3.0.0).
 libpq5:amd64 dépend de libssl3 (>= 3.0.0).
 libpkcs11-helper1:amd64 dépend de libssl3 (>= 3.0.0).
 libpipewire-0.3-modules:amd64 dépend de libssl3 (>= 3.0.0).
 libopusfile0:amd64 dépend de libssl3 (>= 3.0.0).
 libnvme1 dépend de libssl3 (>= 3.0.0).
 libnet-ssleay-perl:amd64 dépend de libssl3 (>= 3.0.0).
 libneon27:amd64 dépend de libssl3 (>= 3.0.0).
 libmariadb3:amd64 dépend de libssl3 (>= 3.0.0).
 libkmod2:amd64 dépend de libssl3 (>= 3.0.0).
 libjim0.82:amd64 dépend de libssl3 (>= 3.0.0).
 libimobiledevice6:amd64 dépend de libssl3 (>= 3.0.0).
 libhdf5-openmpi-103-1:amd64 dépend de libssl3 (>= 3.0.0).
 libhdf5-103-1:amd64 dépend de libssl3 (>= 3.0.0).
 libgrpc29:amd64 dépend de libssl3 (>= 3.0.0).
 libgdal34:amd64 dépend de libssl3 (>= 3.0.0).
 libfsverity0:amd64 dépend de libssl3 (>= 3.0.0).
 libfreerdp2-2:amd64 dépend de libssl3 (>= 3.0.0).
 libfido2-1:amd64 dépend de libssl3 (>= 3.0.0).
 libcryptsetup12:amd64 dépend de libssl3 (>= 3.0.0).
 libcrypt-ssleay-perl dépend de libssl3 (>= 3.0.0).
 libaprutil1:amd64 dépend de libssl3 (>= 3.0.0).
 kmod dépend de libssl3 (>= 3.0.0).
 dillo dépend de libssl3 (>= 3.0.0).
 coreutils dépend de libssl3 (>= 3.0.0).
 bind9-utils dépend de libssl3 (>= 3.0.0).
 bind9-libs:amd64 dépend de libssl3 (>= 3.0.0).
 apache2-bin dépend de libssl3 (>= 3.0.0).

Suppression de libssl3:amd64 (3.1.5-1) ...
Sélection du paquet libssl3t64:i386 précédemment désélectionné.
(Lecture de la base de données... 614181 fichiers et répertoires déjà
installés.)
Préparation du dépaquetage de .../libssl3t64_3.2.1-3_i386.deb ...
Dépaquetage de libssl3t64:i386 (3.2.1-3) ...
[…]

So apt apparently intended to remove libssl3:i386, and replace it with
libssl3t64:i386,
but instead it actually removed libssl3:amd64…

This broke my system, leaving sudo unable to run (so I could not fix this
manually):

$ sudo
sudo: error while loading shared libraries: libcrypto.so.3: cannot open shared
object file: No such file or directory


Fortunately, I ended up finding out about pkexec, and was able to use it to
become root and manually reinstall libcrypto.so.3 by running:
dpkg -i libssl3t64_3.2.1-3_amd64.deb


   * What outcome did you expect instead?
I expected libssl3 to be replaced by libssl3t64 for the same architecture(s)


The version of apt used for the full-upgrade was 2.7.12,
and it attempted to upgrade itself to 2.9.2, later than the above extracts —
but systemctl was also broken:

[…]
Préparation du dépaquetage de .../archives/apt_2.9.2_amd64.deb ...
Dépaquetage de apt (2.9.2) sur (2.7.12) ...
Paramétrage de apt (2.9.2) ...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
shared object file: No such file or directory
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
shared object file: No such file or directory
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
shared object file: No such file or directory
apt-daily-upgrade.timer is a disabled or a static unit not running, not
starting it.
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
shared object file: No such file or directory
systemctl: error while loading shared libraries: libcrypto.so.3: cannot open
shared object file: No such file or directory
apt-daily.timer is a disabled or a static unit not running, not starting it.
[…]

usertags 1071431 + time-t

I should have added that the "apt full-upgrade" run that left the system
with a broken sudo was interrupted by an error, also due to the missing
libcrypto.so.3, and ended with:

"
Préparation du dépaquetage de .../5-postgresql-16_16.3-1_amd64.deb ...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot
open shared object file: No such file or directory
dpkg: avertissement: le sous-processus ancien paquet postgresql-16
script pre-removal a renvoyé un état de sortie d'erreur 127
dpkg: tentative d'exécution du script du nouveau paquet à la place...
systemctl: error while loading shared libraries: libcrypto.so.3: cannot
open shared object file: No such file or directory
dpkg: erreur de traitement de l'archive
/tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb (--unpack) :
  le sous-processus nouveau postgresql-16 paquet pre-removal script a
renvoyé un état de sortie d'erreur 127
Des erreurs ont été rencontrées pendant l'exécution :
  /tmp/apt-dpkg-install-klPmRf/5-postgresql-16_16.3-1_amd64.deb
Erreur : Le délai d’attente est dépassé
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

"

You seem to have packages installed which are not in Debian anymore.
From a quick glance that is
- postgresql-14
- postgresql-15

The problem is basically that those packages require libssl3 while
everything else in-system depends on libssl3t64 and this conflicts with
libssl3. Both provide the same .so library file.

Can you try if this update is doable having only packages available in
Debian? The command "apt list ?obsolete" lists package which are no
longer in the archive. Please ensure that you have no packages from
third-party repo installed.

Sebastian

Thank you Sebastian for your reply.

I am sorry, but it is not possible for me to go back to the pre-
full-upgrade state to try what you suggest.

Anyway, as shown by the extracts quoted, "apt full-upgrade" announced it
was going to remove both libssl3(:amd64 by default on my system) and
libssl3:i386, and install libssl3t64(:amd64) and libssl3t64:i386
instead. So the presence of obsolete packages does not seem to have
interfered.

By looking in the full log for instances of other libraries that had
both :amd64 and :i386 versions, and that were going to be removed in
spite of apparent "dependency problems", I noticed that the installation
of the replacement t64:amd64 version sometimes happened much later than
the removal.

So, my understanding is that, unfortunately, the postgresql-16 install
script error interrupted the full-upgrade before libssl3t64:amd64 had
been installed, which left the system without the libcrypto.so.3 needed
by both systemctl and sudo...

Jean-Guilhem

Okay. This was old testing -> new testing or Bookworm -> testing? Was
this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ?

This is required for the transition.

Now that I think about it, you need both PostgreSQL version since you
need to perform an update of the databse (to get it from 15 to 16).

Let me try to do this later and see what happens. But you have :i386 and
:amd64 binaries. This shouldn't complicate the sitution much since sudo/
systemd and so on depend on the amd64 library only.
Anyway. I will try to spin a Bookworm VM with psql and then update to
testing and check what happens during the update.

Correct. Usually a transition is something like libfoo1 -> libfoo2 where
the package names changes and the name of .so file changes, too. In this
t64 transition however only the package name changes while the library
file itself remains the same. That means thr new (t64) package conflict with
the older (non-t64) and both can't exists at the same time. dpkg then
needs to break the system a bit where it removes libssl3 and later adds
libssl3t64 to the system.

Sebastian

Le 20/05/2024 à 10:11, Sebastian Andrzej Siewior a écrit :

This was old testing -> new testing.
This was just "apt full-upgrade".
postgresql-16 was already present, and was supposed to get upgraded from
16.2-1 to 16.3-1.
Which apparently, according to the error messages quoted above, included
running a pre-removal script, of which old and new versions both failed.

It seems to me that having both :i386 and :amd64 libraries increases the
risk of failure, because of the many "apt" steps that can take place
between the removal of old :amd64 (that may happen close to the
treatment of the :i386 version, like here for libssl3) and install of
t64:amd64. On the contrary, when only :amd64 is present, it seems that
the replacement install closely follows the removal.

Jean-Guilhem

Okay.

how did you have two versions? I couldn't install :amd64 and :i386 of
that package. I tried several bookworm -> testing upgrade but in
bookworm I could install either :i386 or :amd64 version of postgres.
Installing the other version removed the former…
I performed a few upgrades and all succeeded. Anyway to reproduce what
you did?

Sebastian

Le 26/05/2024 à 21:58, Sebastian Andrzej Siewior a écrit :
(As a reminder, it was systemctl:amd64 that failed during upgrade of
postgresql-16, because libssl3:amd64 had been removed "at the same time"
than libssl3:i386, and only libssl3t64:i386 had been installed then —
libssl3t64:amd64 was likely planned to get installed later.)

It was other packages, in the past, that have required :i386 libraries.
I don’t remember which packages now.

For example, I have an old skype:i386 installed (version: 4.3.0.37-1),
that depended on libssl1.0.0. Maybe that caused libssl3:i386 to become
installed through some upgrade path. (Or maybe libssl3 was a dependency
from another :i386 package.)

To reproduce, you would likely have to have some :i386 package
installed, that depended on libssl3:i386. (Or maybe just libssl3:i386
would be enough?)

Jean-Guilhem