Dear Maintainer,
 While upgrade base-files to this version from 13.7 without x32 supporting
 (uninstall or drop x32 arch supporting), fail to install with below message:
--- BEGIN QUOTE ---
******************************************************************************
*
* The base-files package cannot be installed because
* /libx32 is a dangling symbolic link.
*
* This is an unexpected situation. Cannot proceed with the upgrade.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
******************************************************************************
--- END QUOTE ---

 So, I mkdir dummy /usr/libx32 and make symlink as /libx32.
 Then, retry to upgrade base-file to 13.8, it succeeded.

Regards,
 Ohta.

Hi Santiago,

Thank you for forwarding.

Hello Ohta,

I'm glad that the current message was sufficient to let you figure a
workaround. Before jumping to any conclusions, I'd like to better
understand the situation and whether it is a common one. Do you happen
to have backups of the system in questions?

 * Where did /libx32 point before the upgrade?
 * Do you have any :x32 or -x32 packages installed before or after the
   upgrade? Which packages and versions precisely?

I attempted a few related upgrades and was unsuccessful reproducing your
failure thus far. In particular, libc6-x32 is the only :amd64 package
that installs below /libx32 and installing/removing it correctly takes
care of /libx32 in bookworm. Once upgraded to trixie, libc6-x32
installs to /usr/libx32 and base-files handles presence/absence of
/libx32.

In theory, we could handle the situation by deleting such a dangling
link, but that comes with a risk of breaking things. Hence, the current
strategy is giving up and letting the user sort it out.

Helmut

Helmut-San,

Thank you for replying.

1. /libx32 *WAS* symlink from /usr/libx32 .
   This existed, but I didn't use x32 architecture a long time,
   so I removed x32 libs by dpkg/apt.
   This directory (/usr/libx32 ) was empty (perhaps about a week ago).
   Then, this may have been a my mistake,I deleted /usr/libx32 and
   /lib32.

2. I had some x32 architecture libs before upgrading base-files
   to this version (13.8) , previous version (at I did 1.) was
   13.7 .

Hmm... this behavior seems to correct, but, if some user installed
libc6-x32 and some x32 libraries (by some reasons) , then remove
these due to be unused x32 architecture, empty /libx32 (or /usr/libx32)
only remains.

After these user decided to this a empty directory by hand or
automatically, upgrading base-files may occur this (or similar) issue.

I'll leave that up to you, but I think you should mention it
in the README or another document.

thanks,
Ohta.


On Thu, 15 May 2025 10:17:30 +0200 Helmut Grohne <helmut@subdivi.de> wrote:
(snip)

Hi.

Would it make sense that the special protections in preinst
preinst are only done when upgrading from a version < 13.4,
which is the version in which some directories became
symlinks and vice-versa?

This would have the advantage that in cases like this
one the upgrade would happen as normal without prompting
the user (the dangling symlink would continue to be
a dangling symlink).

The con would be that an anomaly of the x32 setup would
remain hidden.

I think it would be correct to assume that most people who
will execute the preinst will do so when upgrading from
bookworm to trixie, so I would agree that the difference
between those two options would be quite small.

Thanks.

To me, this very much looks like a user error. If you delete
/usr/libx32, you are very much on your own.

Can you give instructions on how to reproduce a situation where /libx32
exists but /usr/libx32 does not? Ideally, you describe the release and
architecture you start from, the packages you install/remove/upgrade and
the point where /libx32 exists without /usr/libx32.

Packages may install empty directories. If you choose to delete those,
it is up to you to deal with failing packages.

Helmut

Helmut-San,
Sorry for later a lot.

(snip)


*Prereq:
 1. I installed Debian GNU/Linux for my PC a long time,
   from 2.0 "hamm" or 1.3 "bo".
   Of cource, I replaced a PCs a lot, but OS and softwares were
inherited beyond PCs, HDDs and SDDs.
 2. I added AMD64 archtecture very early timing (perhaps 2005~2006).


*Instruction (I don't test completely due to my poorly
              disk capacity , sorry).

 1. Install older Debian GNU/Linux (i.e. 8 "jessie")
    both for i386 and amd64 on VM capability to get snapshot.
    For example, VirtualBox.

 2. Enable suppot for x32 architecture, see
https://wiki.debian.org/X32Port .
    At least, you should install libc6-x32:amd64 and libc6-dev-x32 .
    Using archive.debian.org is useful.

 3. Dist-Upgrade distribution versions step by step.
     8.0 -> 9.0 ...
    I strongly recommend to get a snapshot of VM
    before apt-get dist-upgrade.

 4. At version 12.0 "bookworm" , you should get snapshot
    this point at least.

 5. Remove all x32 related programs and libraries before installed.
    Then, get snapshot again.

 6. Check whether /usr/libx32 and /lib32 are empty.
     Then, also get snapshot.

 7. If empty, "sudo rm -fR /usr/lib32 /lib32" and get snapshot.

 8. Now, you can dist-upgrade to "sid" .
    If reproduce this issue, you can't dist-upgrade to sid.

 Note:
 As long as the source code of base-files is compared from
 12.4-deb12u11 to 13.8, it can be expected that the this
 reproducable phenomenon will occur at the time of the dist-upgrade
 from Debian 12 "bookworm" to "sid" (or 13 "trixie"),
 so I think it is OK to start item 1. with Debian 12 "bookworm".

Sorry...
Ohta.

---
On Sun, 18 May 2025 18:38:59 +0200 Helmut Grohne <helmut@subdivi.de> wrote:

That hints that the situation may be unusual and maybe not worth adding
more code for.

I don't think you need much disk space. Even a non-minimal installation
should fit into 1GB and most current systems have significantly more
RAM (i.e. you may use tmpfs).

I hope we can skip all of this.

If we just need a bookworm snapshot with x32, the following rune may
work:

    mmdebstrap \
      --aptopt='Acquire::Check-Valid-Until "false"' \
      --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
      --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
      --variant=apt \
      --architectures=amd64,x32 \
      '' \
      /dev/null \
      'deb [arch=amd64] http://snapshot.debian.org/archive/debian/20230610T162914Z unstable main' \
      'deb [arch=x32] http://snapshot.debian.org/archive/debian-ports/20230610T162914Z/ unstable main' \
      --chrooted-customize-hook=bash

Some explanation. mmdebstrap is a fancy alternative for debootstrap. You
don't have to run it as root. We instruct to ignore signature validity
(for use with snapshot.d.o), allow the ports archive keyring, choose
variant apt to install as few packages as possible, enable both amd64
and x32 as architectures, do not specify a suite as it will be implied
from the source, specify /dev/null as output as we're only testing
things, use snapshots at the time of bookworm's release and drop into a
root shell.

I attempted installing libc6-x32 and libc6:x32 and removing them in
either order.

At no point did I see an empty /usr/libx32. It was either populated or
absent. Also /libx32 was never dangling.

Could you go into more detail as to how you got into the problematic
situation?

This sounds like you want to have a preinst failure.

Thus far I see little reason to add support code for the situation at
hand.

Helmut

Helmut-San,

 Thanks for your suggestion.I can do below with my environment as-is.

 But, please give some days to me, because very busy today (and maybe a
 few days). I will try to reproduce #1105811 issue (parhaps until next
 monday),
inspired by your below suggestion.

Sorry and please wait.
Ohta.

On Wed, 21 May 2025 16:28:04 +0200 Helmut Grohne <helmut@subdivi.de> wrote:

Helmut-San,
 Sorry for very, very later to answer.

 In conclusion, I could not reproduce BUG #1105811 with below process.
 Please read below datails, and if you judge that there is no problem
 in below process, I want you to close this BUG, #1105811 .

I AM SORRY.

Ohta.

--- 
I tried to reproduce it in the following process:

A.Build bootstrap tarboll to build testing DOCKER container
  with mmdebootstrap.

 See attached files:
 - bootstrap_1105811.sh  : mmdebootstrap-ing script
 - before_remove_20250325T024113Z.list : Initial installation list.
 - bootstrap_1105811.Mon, 26 May 2025 14:15:20 +0900.log :
   Bootstrapping log.

B. Make DOCKER contatiner by tarball built at A.
   Sample running script :
   docker_test-bug_1105811.sh .

C. Run container (by docker-test-bug_1105811.sh , attached).
   Then, build minimum environment within this container by
   unstable SNAPSHOT 20250325T024113Z (at snapshot.debian.org) .
   See,
   000_dpkg_before_remove_20250325T024113Z.log
   and
   000_ls_before_remove_20250325T024113Z.log

D. Then remove around x32 architecture, see
   000_apt_removing_x32_at_20250325T024113Z.log
   000_dpkg_after_remove_20250325T024113Z.log

E. Try to reproduce BUG #1105811 at this time, but not reproduced.
   So, I revert changed of D, revert to C.

F. Upgrade to SNAPSHOT 20250414T025349Z from C.
   See,
   000_apt_upgrade_to_20250414T025349Z_from_20250325T024113Z.log .

G. Try to remove around x32 arch from F. See,
   001_dpkg_after_remove_x32_20250414T025349Z.log
   001_ls_root_usr_after_remove_20250414T025349Z.log

H. This bug seems not to reproduce at this time, revert changes G.
   then,  insert dummy file to /usr/libx32 to G. See,
   001_ls_x32_after_remove_20250414T025349Z.log

I. Upgrade to SNAPSHOT 20250515T023807Z . See,
   002_apt_upgrade_straight_to_20250515T023807Z_from_20250414T025349Z.log
   002_dpkg_list_20250515T023807Z.log
   002_ls_root_ls_20250515T023807Z.log
   002_x32_straight_20250515T023807Z.log

J. But, this issue hasn't reproduced.

K. So, revert to SNAPSHOT 20250414T025349Z *without* dummy,
   In short, I returned to the state of G.
   Then, upgrade to SNAPSHOT 20250515T023807Z . See,
       003_apt_upgrade_without_dummy_to_20250515T023807Z_from_20250414T025349Z.log
    003_dpkg_l_20250515T023807Z.log
    003_ls_20250515T023807Z.log
    003_ls_remove_libx32_and_usr.libx32_20250414T025349Z.log

L. Remove dummy file within /usr/libx32 . See,
   003_ls_remove_libx32_and_usr.libx32_20250414T025349Z.log

M. Empty directory, /usr/libx32 exitsts at this time.

---
With above proccesses, I was wrong. My issue is by only my another
issue, My decidion of reporting BUG #1105811 were wrong.

---
On Fri, 23 May 2025 13:46:25 +0900 "K.Ohta" <whatisthis.sowhat@gmail.com> wrote:

severity 1105811 normal
close 1105811
thanks

Thanks a lot for all the work in trying to reproduce the problem (even
if it was not a bug in base-files after all).

Closing now.