Upgrade to base-files 13.6 broken by symlink /lib64 -> /usr/lib

[gri573]

Description

I think the title sums it up pretty well. The upgrade fails with the following error message:

Preparing to unpack .../base-files_13.6_arm64.deb ...
*************************************************************************
*
* The base-files package cannot be installed because
* /lib64 is a symbolic link and not pointing at /usr/lib64 exactly.
*
* This is an unexpected situation. Cannot proceed with the upgrade.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
*************************************************************************

removing the /lib64 symlink appears to be a workaround. This works on a default installation of the pinenote debian image, but users may have installed packages that rely on /lib64, causing those to stop working.

system details

I have tested this on a pinenote community edition from batch 2 (as far as I know, at least it still came with a UART dongle and already has a passive pen)

[WilsontheWolf]

Same issue here. Pinenote batch 2. As a note, it appears that /lib64 is pointing to usr/lib instead of usr/lib64. Not sure what causes that. I have a copy of the latest image on my os2 which I haven't updated yet and it appears to not have a /lib64 or /usr/lib64 at all.

[psstoyanov]

Same here

[gri573]

This turns out to be an issue with upstream debian's base-files (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077866) or systemd (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079329), depending on whom you ask, but it is not caused by anything related to the pinenote other than being an arm64 system.

Keeping this issue open might still be useful so people can find it, but I will update my initial comment warning about the risks associated with deleting /lib64

[Xanatos00]

Same issue here. Pinenote batch 2. As a note, it appears that /lib64 is pointing to usr/lib instead of usr/lib64. Not sure what causes that. I have a copy of the latest image on my os2 which I haven't updated yet and it appears to not have a /lib64 or /usr/lib64 at all.

Same here.
No /lib64/ or /usr/lib64/

Removed /lib64 link.
Re-try updates, everything works

[ewenmcneill]

To record some discussion from chat, and those Debian bugs, for a Debian system on arm64 (like the PineNote), Debian (and thus base-files) expect there's no need for an /lib64 symlink (it's a new enough port Debian just used /lib for the 64-bit libraries). But if /lib64 does exist as a symlink, Debian expects it to point at /usr/lib64. Which doesn't seem to be the case in the PineNote batch 2 (which has /lib64 pointing at /usr/lib, like /lib).

I'm not clear if the problematic /lib64 symlink shipped withe PineNote batch 2 factory image, or is being auto-created at boot. by systemd. (systemd tries to auto-create a bunch of similar links to support "works with no permanent / disk" boots for other distros.) If it is created by systemd, then it's possible to avoid systemd recreating the symlink wrong by manually creating a chain of symlinks (/lib64 -> /usr/lib64 -> /usr/lib) -- ie, the same effect as the one in the base image, but with the first symlink looking the way Debian expects.

Ewen