It was discovered that some versions of systemd and systemd-nspawn
install a /lib64 symlink [1], pointing to /usr/lib/<triplet>. This is
wrong.

Regardless of systemd doing the wrong thing here, the preinst check
fails when the wrong link exists.

base-files might need to apply a workaround, possibly fixing up the
symlink.

Most reports of this problem were about arm64 systems, but it is
unclear (to me) if the problem is really limited to such systems.

A discussion about what to do for base-files would be good, thus
filing this bug.

Chris


[1] https://github.com/systemd/systemd/issues/33919

I'll note that #1076491 was on amd64.

Chris

Hi Santiago, Chris and Luca,

First of all, huge thanks for locating the cause of this. I was looking
at it for a week now and didn't figure the root cause. Then thanks for
fixing it in systemd right away.

I think Luca asked why we have the preinst check in the first place and
this warrants a longer answer.

If the link exists in a different way than in base-files' data.tar, dpkg
will observe that other packages also own this directory and dpkg will
then assume that whatever is in the filesystem is what those other
packages wanted it to be (as it only keeps track of which paths are
managed and not what filetypes they have). Thus it sees that base-files'
version of /lib64 is in conflict with another package's version of it
and gives up raising an unpack error. We can only actually unpack if
/lib64 already is a symlink pointing in exactly the way its data.tar
specifies. Hence, the check is attempts giving a better error message
for what would later become an unpack error.

I concur. Patch attached. I manually tested the conversion on an arm64
qemu guest running bookworm's systemd-nspawn to create the situation.

The systemd change indicates that more /lib64 links are affected. I
suggest generally replacing /lib64 -> usr/lib/$DEB_HOST_MULTIARCH.

In theory, this could break the dynamic loader. Assume that we have this
symlink and then we unpack a pre-trixie libc6 for one of amd64, loong64,
mips64el, ppc64, ppc64el or sparc64. Doing so would redirect the unpack
of the dynamic loader entry point via the aforementioned symlink to
usr/lib/$DEB_HOST_MULTIARCH and hence /usr/lib64 might lack the dynamic
loader. Thus for playing extra safe (and I have no evidence of this
being a real issue), we might also want to check whether /usr/lib64 has
a dynamic loader. I have not implemented this aspect, but we can do it
if we deem it necessary.

Helmut

We believe that the bug you reported is fixed in the latest version of
base-files, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1077866@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila <sanvila@debian.org> (supplier of updated base-files package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 04 Aug 2024 23:30:00 +0200
Source: base-files
Architecture: source
Version: 13.5
Distribution: unstable
Urgency: medium
Maintainer: Santiago Vila <sanvila@debian.org>
Changed-By: Santiago Vila <sanvila@debian.org>
Closes: 1077863 1077866
Changes:
 base-files (13.5) unstable; urgency=medium
 .
   [ Chris Hofstaedtler ]
   * Fix typo in preinst: lib64 -> libx32. Closes: #1077863.
   [ Helmut Grohne ]
   * Work around /lib64 link created by systemd-nspawn. Closes: #1077866.
   [ Santiago Vila ]
   * Add lintian overrides for the directories that have become symlinks.
Checksums-Sha1:
 ec2800069e854332de23df3933cf2b23df0b38d5 1100 base-files_13.5.dsc
 ae6c94c25bc4dd553d22351d4b876834144c5c77 68200 base-files_13.5.tar.xz
 17c0e28a62cfed67b1d17529abc3325d74b4761a 5160 base-files_13.5_source.buildinfo
Checksums-Sha256:
 e5e4772aae38b90b23b882f18a277f9c9dc72f1861a0743bd26ec1af0a056492 1100 base-files_13.5.dsc
 a478a680b60c63c0ae78fef166ae681adc945b29a2aea4c2d03ba2921b72d419 68200 base-files_13.5.tar.xz
 a9f6583d39223778fa6ab4cd2ba1883cedcbc5c4c64267d00456e4d9dd0058bf 5160 base-files_13.5_source.buildinfo
Files:
 0e639407f7bbd97dd4525ba3355b5d0f 1100 admin required base-files_13.5.dsc
 9f6a4b45ac4a245a951bbf121c2b3362 68200 admin required base-files_13.5.tar.xz
 0cb7c029f29e1f6a3a2cac5b59b8f717 5160 admin required base-files_13.5_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE1Uw7+v+wQt44LaXXQc5/C58bizIFAmav9TAACgkQQc5/C58b
izL8eAgAggaYqZYDC6LRuUPi2jGdHrgn/27FhfzKFZQwew749IHFE5S1lXmBm2IB
FFAlz41gXAU9KIGU0WxhAwNltqhpkFSZz7p+Bl+9rdLidJTZXLzrzF7iwMg8/8dj
XcNT+PgU2eev65fy1bFutt6iYI8KZaomhla1uKVlKzxNRqXTW9+DzVj7kuYAR2XP
t6XKkp0O3ZyPbEolgeDZQR64+AmbIPLHGLniGxGrz2kK1p1D8lCndhL9dna86KUU
VBawZ7mQ34TVQR9+AUHLZX+ghcpT0WE7M+xQV+XnWa1uokJzsxUXZw8E3+KR7dAR
b1bJSdHnc9aCOr/FMt0G3pe6pjfsMw==
=FNws
-----END PGP SIGNATURE-----

Hi,

systemd 256.5-1 changed the behaviour and now creates a lib64 -> usr/lib
symlink so the workaround here no longer works. This should fix it:

--- a/debian/preinst
+++ b/debian/preinst
@@ -7,7 +7,7 @@ if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then
      if [ -L "$DPKG_ROOT/$d" ]; then
        target=$(readlink "$DPKG_ROOT/$d")
        if [ "$target" != "usr/$d" ]; then
-        if [ "$d" = lib64 ] && [ "$target" = "usr/lib/#DEB_HOST_MULTIARCH#" ]; then
+        if [ "$d" = lib64 ] && [ "$target" = "usr/lib/x86_64-linux-gnu" ] || [ "$target" = "usr/lib" ]; then
            # Work around https://github.com/systemd/systemd/issues/33919
            echo "Fixing bad /$d symbolic link created by systemd-nspawn."
            if [ -d "$DPKG_ROOT/usr/$d" ]; then


Do we have a related systemd bug to stop creating those links?

Cheers Jochen

* Helmut Grohne <helmut@subdivi.de> [2024-08-04 22:13]:

Hi Jochen,

Thanks for reporting.

I'd appreciate if we could defer applying this fix a little, because

we should fix the cause before the symptom and then also reference the
systemd fix in the base-files.preinst in order to get an idea when it is
applicable to remove the workaround when looking at this in five years.

Did you already report this bug on the systemd side upstream or
downstream? Indicating "no" allows one of us filing it while avoiding
duplicates or you may do it yourself.

Helmut

Hi Helmut,

* Helmut Grohne <helmut@subdivi.de> [2024-08-22 09:32]:

Agreed.

no. Feel free to do so.

As commented in #debian-usrmerge I am not sure about the use case in
systemd.

Cheers Jochen