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 <hel...@subdivi.de> [2024-08-04 22:13]:
Control: tags -1 + patch Hi Santiago, Chris and Luca, On Sat, Aug 03, 2024 at 05:46:18PM +0200, Chris Hofstaedtler wrote:It was discovered that some versions of systemd and systemd-nspawn install a /lib64 symlink [1], pointing to /usr/lib/<triplet>. This is wrong.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.Regardless of systemd doing the wrong thing here, the preinst check fails when the wrong link exists.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.base-files might need to apply a workaround, possibly fixing up the symlink.I concur. Patch attached. I manually tested the conversion on an arm64 qemu guest running bookworm's systemd-nspawn to create the situation.Most reports of this problem were about arm64 systems, but it is unclear (to me) if the problem is really limited to such systems.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
diff --minimal -Nru base-files-13.4/debian/changelog
base-files-13.4+nmu1/debian/changelog
--- base-files-13.4/debian/changelog 2024-08-01 12:30:00.000000000 +0200
+++ base-files-13.4+nmu1/debian/changelog 2024-08-04 11:43:12.000000000
+0200
@@ -1,3 +1,10 @@
+base-files (13.4+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around /lib64 link created by systemd-nspawn. Closes: #1077866.
+
+ -- Helmut Grohne <hel...@subdivi.de> Sun, 04 Aug 2024 11:43:12 +0200
+
base-files (13.4) unstable; urgency=medium
[ Helmut Grohne ]
diff --minimal -Nru base-files-13.4/debian/preinst
base-files-13.4+nmu1/debian/preinst
--- base-files-13.4/debian/preinst 2024-08-01 11:00:00.000000000 +0200
+++ base-files-13.4+nmu1/debian/preinst 2024-08-04 11:43:10.000000000 +0200
@@ -5,8 +5,19 @@
msg=
for d in bin lib lib32 lib64 libo32 lib64 sbin; do
if [ -L "$DPKG_ROOT/$d" ]; then
- if [ "$(readlink "$DPKG_ROOT/$d")" != "usr/$d" ]; then
- msg="/$d is a symbolic link and not pointing at usr/$d exactly"
+ target=$(readlink "$DPKG_ROOT/$d")
+ if [ "$target" != "usr/$d" ]; then
+ if [ "$d" = lib64 ] && [ "$target" = "usr/lib/#DEB_HOST_MULTIARCH#" ];
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
+ ln -sf "usr/$d" "$DPKG_ROOT/$d"
+ else
+ rm "$DPKG_ROOT/$d"
+ fi
+ else
+ msg="/$d is a symbolic link and not pointing at usr/$d exactly"
+ fi
elif [ ! -d "$DPKG_ROOT/usr/$d" ]; then
msg="/$d is a dangling symbolic link"
fi
signature.asc
Description: PGP signature
