Re: Bookworm upgrade, usrmerge failure

[Bastien Durel]

Le lundi 12 juin 2023 à 14:02 -0400, Jeffrey Walton a écrit :
> On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel
>  wrote:
> > 
> > Hello,
> > 
> > During bookworm upgrade, I ran into some usrmerge failures, which
> > led
> > to an hard-to-fix situation
> > 
> > Paramétrage de usrmerge (35) ...
> > 
> > FATAL ERROR:
> > Both /lib/x86_64-linux-gnu/libidn.so.11 and /usr/lib/x86_64-linux-
> > gnu/libidn.so.11 exist.
> > 
> > You can try correcting the errors reported and running again
> > /usr/lib/usrmerge/convert-usrmerge until it will complete without
> > errors.
> > Do not install or update other Debian packages until the program
> > has been run successfully.
> > 
> > E: usrmerge failed.
> > 
> > root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version
> > `GLIBC_2.29' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.28' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.33' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.34' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.25' not found (required by /lib/x86_64-linux-
> > gnu/libcrypt.so.1)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.36' not found (required by /lib/x86_64-linux-
> > gnu/libcrypt.so.1)
> > root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11
> > Erreur de segmentation (core dumped)
> > root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
> > (required by ls)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > 
> > As no system tool was usable in this situation (dpkg crashed too),
> > I
> > powered-off the machine and restored it from backup. I then
> > installed
> > usrmerge on bullseye, fixed the problems, then done the bookworm
> > upgrade without any other problems.
> > 
> > As usrmerge is mandatory on bookworm ; and usrmerge failure during
> > upgrade leads to (could lead to ?) big problems ; shouldn't its
> > installation be advised in 4.1 or 4.2 chapters of the upgrade guide
> > ?
> > 
> > I know 5.1.14 says merged-/usr is now required ; but it does not
> > warn
> > about failures, and I don't think I'm the only one who don't read
> > the
> > next chapter before starting upgrade ;)
> 
> I wonder if you have a bunch of stale symlinks...
> 
> Does symlinks report any dangling links for the problem shared
> libraries?
> 
>     sudo symlinks -r / | grep dangling
> 
> If the list of dangling looks safe to clean-up, then you can run
> 
>     sudo symlinks -r -d /
> 
> Jeff
> 

Hello.

I have a bunch of them, here a those in /usr : 

dangling: /usr/bin/rust-llvm-dwp -> llvm-dwp-14
dangling: /usr/bin/clhsdb -> /etc/alternatives/clhsdb
dangling: /usr/bin/rust-lld -> lld-14
dangling: /usr/bin/rust-clang -> clang-14
dangling: /usr/bin/x-terminal-emulator -> /etc/alternatives/x-terminal-emulator
dangling: /usr/bin/hsdb -> /etc/alternatives/hsdb
dangling: /usr/share/phpmyadmin/docs/html -> ../../doc/phpmyadmin/html
dangling: /usr/share/man/man1/policyeditor.1.gz -> 
/etc/alternatives/policyeditor.1.gz
dangling: /usr/share/man/man1/itweb-settings.1.gz -> 
/etc/alternatives/itweb-settings.1.gz
dangling: /usr/share/man/man1/x-terminal-emulator.1.gz -> 
/etc/alternatives/x-terminal-emulator.1.gz
dangling: /usr/share/man/man3/SSL.3ssl.gz -> ssl.3ssl.gz
dangling: /usr/share/man/man3/cerfcf.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerfcl.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerfl.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerff.3.gz -> cerf.3.gz
dangling: /usr/share/pyshared/paste/evalexception/media/MochiKit.packed.js -> 
../../../../javascript/mochikit/MochiKit.js
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-util-buffer.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-util-buffer.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-mode.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-mode.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-mode-autoloads.el 
-> /usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-mode-autoloads.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-project.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-project.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php.el

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 09:35:13PM +, bw wrote:
> Right now I'm studying and trying to come up with a way to identify duplicate
> filenames and/or symlinks between /bin /sbin /lib, and /usr/bin /usr/sbin
> /usr/lib.  I bet someone on the list could do it in a one line command.

Well, it's not *that* simple.  Bear in mind that the files in question
are not directly inside /lib and /usr/lib, but instead are inside
subdirectories (e.g. /lib/x86_64-linux-gnu).  So there has to be a
recursive discovery component.

Something like this might work as a starting point.  Note that it
assumes duplicate filename entries will be encountered in pairs, not
in larger groups.  I can't vouch for how well it'll handle finding 3 or
more of the same name.

I'm also not sure if the list of starting directories in the findem
function is complete.

#!/bin/bash

findem() {
find /bin /lib /lib32 /lib64 /sbin /usr/bin /usr/lib /usr/lib32 \
/usr/lib64 /usr/sbin \( -type f -o -type l \) -print0
}
declare -A found

while IFS= read -rd '' f; do
name=${f##*/}
if [[ ${found[x$name]} ]]; then
printf '%s\n' "$f" "${found[x$name]}"
fi
found[x$name]=$f
done < <(findem)

Re: Bookworm upgrade, usrmerge failure

[bw]

in-reply-to=

>> On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
...
>>Well, that's somewhat terrifying.  I looked at bugs.debian.org/usrmerge
>>and didn't see any bugs like this already reported.

Sorry for the out of thread posting, but I've been studying the usrmerge issue 
for awhile because I use systems that have been cloned and redeployed on a few 
home machines since 2017.  I understand that some pkgs thru the yrs propagated 
symlinks somewhat randomly (haphazardly?) between lib,bin,sbin and their 
counterparts in usr, or vice-versa.

My current understanding is that if there are duplicate binaries or symlinks, 
this can be an issue when installing usrmerge pkg, and I'd like to minimize the 
annoyance.

Even though there a very few bugs active in debian bugtracker against usrmerge, 
a websearch for 'usrmerge problem' might show that there are possible issues 
that some users need to be proactive in solving IMHO.

Right now I'm studying and trying to come up with a way to identify duplicate 
filenames and/or symlinks between /bin /sbin /lib, and /usr/bin /usr/sbin 
/usr/lib.  I bet someone on the list could do it in a one line command.

I found what looks like a nice oneliner, but it takes some work.  You have to 
create a dir, then symlinks, then run:

awk -F'/' '{
  f = $NF
  a[f] = f in a? a[f] RS $0 : $0
  b[f]++ }
  END{for(x in b)
if(b[x]>1)
  printf "Duplicate Filename: %s\n%s\n",x,a[x] }' <(find -L . -type f)
# 
# and -maxdepth 3 or so to remove the /lib/modules/ clutter

TIA for pursuing the issue, and the attention to issues like this.
L8r,
bw

Re: Bookworm upgrade, usrmerge failure

[Jeffrey Walton]

On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel
 wrote:
>
> Hello,
>
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
>
> Paramétrage de usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libidn.so.11 and 
> /usr/lib/x86_64-linux-gnu/libidn.so.11 exist.
>
> You can try correcting the errors reported and running again
> /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
> Do not install or update other Debian packages until the program
> has been run successfully.
>
> E: usrmerge failed.
>
> root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge
> /usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
> found (required by /usr/bin/perl)
> /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not 
> found (required by /usr/bin/perl)
> /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not 
> found (required by /usr/bin/perl)
> /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not 
> found (required by /usr/bin/perl)
> /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/x86_64-linux-gnu/libcrypt.so.1)
> /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not 
> found (required by /lib/x86_64-linux-gnu/libcrypt.so.1)
> root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11
> Erreur de segmentation (core dumped)
> root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11
> ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required 
> by ls)
> ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required 
> by /lib/x86_64-linux-gnu/libselinux.so.1)
> ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required 
> by /lib/x86_64-linux-gnu/libselinux.so.1)
> ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required 
> by /lib/x86_64-linux-gnu/libselinux.so.1)
>
> As no system tool was usable in this situation (dpkg crashed too), I
> powered-off the machine and restored it from backup. I then installed
> usrmerge on bullseye, fixed the problems, then done the bookworm
> upgrade without any other problems.
>
> As usrmerge is mandatory on bookworm ; and usrmerge failure during
> upgrade leads to (could lead to ?) big problems ; shouldn't its
> installation be advised in 4.1 or 4.2 chapters of the upgrade guide ?
>
> I know 5.1.14 says merged-/usr is now required ; but it does not warn
> about failures, and I don't think I'm the only one who don't read the
> next chapter before starting upgrade ;)

I wonder if you have a bunch of stale symlinks...

Does symlinks report any dangling links for the problem shared libraries?

sudo symlinks -r / | grep dangling

If the list of dangling looks safe to clean-up, then you can run

sudo symlinks -r -d /

Jeff

Re: Bookworm upgrade, usrmerge failure

[Sven Joachim]

On 2023-06-12 10:24 -0400, Greg Wooledge wrote:

> On Mon, Jun 12, 2023 at 09:45:15AM -0400, Greg Wooledge wrote:
>> I think I might try grabbing an older-than-buster version of debootstrap
>> out of snapshot.debian.org and see if I can manage to reproduce something.
>> But don't count on my success.
>
> I've succeeded in *partially* reproducing this error, but not fully.
> My resulting state simply has usrmerge failing with the OP's error
> message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
> giving the same error again.  I do not get the GLIBC errors, nor do I
> get an unusable system.
>
> Here's what I did:
>
> 1) Start from my bookworm amd64 system.
> 2) Install bullseye using debootstrap into /stuff/bullseye-base.
> 3) Copy that directory to /stuff/bullseye-with-old-debootstrap.
> 4) Chroot into bullseye-with-old-debootstrap and apt-get install debootstrap.
> 5) Download 
> http://snapshot.debian.org/archive/debian/20180603T165432Z/pool/main/d/debootstrap/debootstrap_1.0.101_all.deb
>  from outside the chroot.
> 6) Chroot into bullseye-with-old-debootstrap and dpkg -i 
> debootstrap_1.0.101_all.deb
> 7) Chroot into bullseye-with-old-debootstrap and debootstrap bullseye into 
> /bullseye2.
> 8) Move bullseye-with-old-debootstrap/bullseye2 to /stuff/bullseye-unmerged.
> 9) Verify that bullseye-unmerged has separate /bin and /lib directories.
> 10) Copy /stuff/bullseye-unmerged to /stuff/bullseye-upgrade-test.
> 11) Chroot into bullseye-upgrade-test and copy 
> /lib/x86_64-linux-gnu/libz.so.1.2.11 to /usr/lib/x86_64-linux-gnu/ and make 
> /usr/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11
> 12) Chroot into bullseye-upgrade-test and edit sources.list and apt-get 
> update and apt-get install usrmerge.
>
> And the resulting output:
>
> ===
> [...]
> Setting up usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
> /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 exist.
>
> You can try correcting the errors reported and running again
> /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
> Do not install or update other Debian packages until the program
> has been run successfully.

I guess the error message here could be improved, since to the many
users it is probably not obvious *how* to fix the problem.  Assume
convert-usrmerge reports something like this:

,
| Both /lib/x86_64-linux-gnu/foo and /usr/lib/x86_64-linux-gnu/foo exist.
`

Then run

$ dpkg -S /lib/x86_64-linux-gnu/foo /usr/lib/x86_64-linux-gnu/foo

Very likely the output will be something like this:

,
| bar: /lib/x86_64-linux-gnu/foo
| dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/foo
`

In other words, one of the duplicate files belongs to package bar, and
the other one is unknown to dpkg.  That one should be deleted or moved
out of the way, the other one left alone.

> root@unicorn:/# perl -e 'print "hello world\n"'
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> hello world
> root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").

FWIW, these messages are harmless.  The current locale is missing in the
chroot, and perl complains about that.  You will not see this during
package upgrades because Debian carries a patch to suppress it when
running perl from a maintainer script[1].

> The minimal debootstrap system has libidn2 (which is in /usr/lib/x*)
> but not libidn, so I wasn't able to reproduce the OP's setup faithfully.
> I figured using a copy of libz (which is in /lib/x*) might suffice.
>
> Has anyone else ever run into this before,

Not personally, but I suspect it might happen on a few old installations
that had been upgraded over the years.  Packages have moved libraries
from /usr/lib to /lib or vice versa, and for instance in the case of a
dpkg database corruption where the *.list file that belongs to a package
becomes empty dpkg will not remove the old files which now come to bite
you.  Such incidents might have happened 10 years ago without being
noticed.

So this problem falls into the "should not happen, but could happen"
category.

> or have any insight into how
> the OP's system became unusable as a result?

No, I do not see this.  In my book that falls into the "cannot happen"
category which is notoriously hard to reproduce or debug.

Cheers,
   Sven


1. 

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 09:45:15AM -0400, Greg Wooledge wrote:
> I think I might try grabbing an older-than-buster version of debootstrap
> out of snapshot.debian.org and see if I can manage to reproduce something.
> But don't count on my success.

I've succeeded in *partially* reproducing this error, but not fully.
My resulting state simply has usrmerge failing with the OP's error
message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
giving the same error again.  I do not get the GLIBC errors, nor do I
get an unusable system.

Here's what I did:

1) Start from my bookworm amd64 system.
2) Install bullseye using debootstrap into /stuff/bullseye-base.
3) Copy that directory to /stuff/bullseye-with-old-debootstrap.
4) Chroot into bullseye-with-old-debootstrap and apt-get install debootstrap.
5) Download 
http://snapshot.debian.org/archive/debian/20180603T165432Z/pool/main/d/debootstrap/debootstrap_1.0.101_all.deb
 from outside the chroot.
6) Chroot into bullseye-with-old-debootstrap and dpkg -i 
debootstrap_1.0.101_all.deb
7) Chroot into bullseye-with-old-debootstrap and debootstrap bullseye into 
/bullseye2.
8) Move bullseye-with-old-debootstrap/bullseye2 to /stuff/bullseye-unmerged.
9) Verify that bullseye-unmerged has separate /bin and /lib directories.
10) Copy /stuff/bullseye-unmerged to /stuff/bullseye-upgrade-test.
11) Chroot into bullseye-upgrade-test and copy 
/lib/x86_64-linux-gnu/libz.so.1.2.11 to /usr/lib/x86_64-linux-gnu/ and make 
/usr/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11
12) Chroot into bullseye-upgrade-test and edit sources.list and apt-get update 
and apt-get install usrmerge.

And the resulting output:

===
[...]
Setting up usrmerge (35) ...

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.11 exist.

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error 
exit status 1
Processing triggers for libc-bin (2.36-9) ...
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@unicorn:/# perl -e 'print "hello world\n"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
hello world
root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.11 exist.

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

root@unicorn:/# perl -e 'print "hello world\n"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
hello world
root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
/usr/lib/x86_64-linux-gnu/libz.so.1.2.11 exist.

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

root@unicorn:/# 
===

The minimal debootstrap system has libidn2 (which is in /usr/lib/x*)
but not libidn, so I wasn't able to reproduce the OP's setup faithfully.
I figured using a copy of libz (which is in /lib/x*) might suffice.

Has anyone else ever run into this before, or have any insight into how
the OP's system became unusable as a result?

Re: Bookworm upgrade, usrmerge failure

[Greg Wooledge]

On Mon, Jun 12, 2023 at 11:24:00AM +0200, Bastien Durel wrote:
> 
> During bookworm upgrade, I ran into some usrmerge failures, which led
> to an hard-to-fix situation
> 
> Paramétrage de usrmerge (35) ...
> 
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libidn.so.11 and 
> /usr/lib/x86_64-linux-gnu/libidn.so.11 exist.
> 
> You can try correcting the errors reported and running again
> /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
> Do not install or update other Debian packages until the program
> has been run successfully.
> 
> E: usrmerge failed.

Well, that's somewhat terrifying.  I looked at bugs.debian.org/usrmerge
and didn't see any bugs like this already reported.

Next, I wondered about reproducing this with a minimal system.  So I
looked at debootstrap.  But as it turns out, debootstrap gives you a
system with an already-merged /usr, so it's not helpful in setting up
a minimal chroot-able system where we can try to reproduce the failure.

According to  one would need a version
of debootstrap between 1.0.87 and 1.0.101, and according to
 even buster has version 1.0.114.

I think I might try grabbing an older-than-buster version of debootstrap
out of snapshot.debian.org and see if I can manage to reproduce something.
But don't count on my success.

Bookworm upgrade, usrmerge failure

[Bastien Durel]

Hello,

During bookworm upgrade, I ran into some usrmerge failures, which led
to an hard-to-fix situation

Paramétrage de usrmerge (35) ...

FATAL ERROR:
Both /lib/x86_64-linux-gnu/libidn.so.11 and 
/usr/lib/x86_64-linux-gnu/libidn.so.11 exist.

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.

root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge
/usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
(required by /usr/bin/perl)
/usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found 
(required by /usr/bin/perl)
/usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found 
(required by /usr/bin/perl)
/usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found 
(required by /usr/bin/perl)
/usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found 
(required by /lib/x86_64-linux-gnu/libcrypt.so.1)
/usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found 
(required by /lib/x86_64-linux-gnu/libcrypt.so.1)
root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11
Erreur de segmentation (core dumped)
root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11
ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required 
by ls)
ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required 
by /lib/x86_64-linux-gnu/libselinux.so.1)
ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found (required 
by /lib/x86_64-linux-gnu/libselinux.so.1)
ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required 
by /lib/x86_64-linux-gnu/libselinux.so.1)

As no system tool was usable in this situation (dpkg crashed too), I
powered-off the machine and restored it from backup. I then installed
usrmerge on bullseye, fixed the problems, then done the bookworm
upgrade without any other problems.

As usrmerge is mandatory on bookworm ; and usrmerge failure during
upgrade leads to (could lead to ?) big problems ; shouldn't its
installation be advised in 4.1 or 4.2 chapters of the upgrade guide ?

I know 5.1.14 says merged-/usr is now required ; but it does not warn
about failures, and I don't think I'm the only one who don't read the
next chapter before starting upgrade ;)

Regards,

-- 
Bastien