Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1197898 > unrolled thread

Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…

Started byJean-Guilhem Cailton <jgc@arkemie.com>
First post2024-05-19 08:30 +0200
Last post2024-05-29 19:30 +0200
Articles 9 — 2 participants

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo… Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-19 08:30 +0200
    Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…) Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-19 10:10 +0200
    Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…)) Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-19 16:30 +0200
      Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…)) Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2024-05-19 23:00 +0200
        Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…)) Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-20 09:10 +0200
          Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo… Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2024-05-20 10:20 +0200
            Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo… Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-20 12:30 +0200
              Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo… Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2024-05-26 22:10 +0200
                Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo… Jean-Guilhem Cailton <jgc@arkemie.com> - 2024-05-29 19:30 +0200

#1197898 — Bug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-19 08:30 +0200
SubjectBug#1071431: libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…
Message-ID<IFIdr-em2a-1@gated-at.bofh.it>
Package: libssl3t64
Version: 3.2.1-3
Severity: important

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.
[…]


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'testing'), (500, 'stable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libssl3t64 depends on:
ii  libc6     2.38-11
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g    1:1.3.dfsg-3.1

libssl3t64 recommends no packages.

libssl3t64 suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1197902 — Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…)

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-19 10:10 +0200
SubjectBug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…)
Message-ID<IFJMd-en2i-1@gated-at.bofh.it>
In reply to#1197898

[Multipart message — attachments visible in raw view] — view raw

usertags 1071431 + time-t

[toc] | [prev] | [next] | [standalone]

#1197933 — Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-19 16:30 +0200
SubjectBug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))
Message-ID<IFPHX-eqtV-5@gated-at.bofh.it>
In reply to#1197898

[Multipart message — attachments visible in raw view] — view raw

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)

"

[toc] | [prev] | [next] | [standalone]

#1197970 — Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))

FromSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date2024-05-19 23:00 +0200
SubjectBug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))
Message-ID<IFVNn-etYU-3@gated-at.bofh.it>
In reply to#1197933
On 2024-05-19 16:18:59 [+0200], Jean-Guilhem Cailton wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#1198004 — Bug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-20 09:10 +0200
SubjectBug#1071431: [Pkg-openssl-devel] Bug#1071431: Info received (Bug#1071431: Acknowledgement (libssl3t64: apt full-upgrade replaced libssl3:amd64 with libssl3t64:i386, breaking sudo…))
Message-ID<IG5jH-eA68-9@gated-at.bofh.it>
In reply to#1197970

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1198009

FromSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date2024-05-20 10:20 +0200
Message-ID<IG6pr-eAHn-5@gated-at.bofh.it>
In reply to#1198004
On 2024-05-20 08:59:22 [+0200], Jean-Guilhem Cailton wrote:
> 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.

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

> 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.

This is required for the transition.

> 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.

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.

> 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...

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.

> Jean-Guilhem

Sebastian

[toc] | [prev] | [next] | [standalone]

#1198037

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-20 12:30 +0200
Message-ID<IG8rf-eBSu-5@gated-at.bofh.it>
In reply to#1198009

[Multipart message — attachments visible in raw view] — view raw

Le 20/05/2024 à 10:11, Sebastian Andrzej Siewior a écrit :
> Okay. This was old testing -> new testing or Bookworm -> testing? Was
> this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ?

This was old testing -> new testing.
This was just "apt full-upgrade".

>> 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.
> 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).
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.

> 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.
>
>> 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...
> 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.
>

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

[toc] | [prev] | [next] | [standalone]

#1198793

FromSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date2024-05-26 22:10 +0200
Message-ID<IIslP-g2rh-7@gated-at.bofh.it>
In reply to#1198037
On 2024-05-20 12:21:30 [+0200], Jean-Guilhem Cailton wrote:
> Le 20/05/2024 à 10:11, Sebastian Andrzej Siewior a écrit :
> > Okay. This was old testing -> new testing or Bookworm -> testing? Was
> > this "apt upgrade && apt dist-upgrade" or just "apt dist-upgrade" ?
> 
> This was old testing -> new testing.
> This was just "apt full-upgrade".

Okay.

> 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.

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?

> Jean-Guilhem

Sebastian

[toc] | [prev] | [next] | [standalone]

#1199157

FromJean-Guilhem Cailton <jgc@arkemie.com>
Date2024-05-29 19:30 +0200
Message-ID<IJvhD-gFMQ-7@gated-at.bofh.it>
In reply to#1198793

[Multipart message — attachments visible in raw view] — view raw

Le 26/05/2024 à 21:58, Sebastian Andrzej Siewior a écrit :
>> 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.
> 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?
>
>

I have only version :amd64 of postgresql.
(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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web