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. https://bugs.debian.org/508764
