• Bug#1105811: AMD64: Unavailable to upgrade without libx32

    From Santiago Vila@21:1/5 to All on Sun May 18 13:40:01 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Grohne@21:1/5 to K.Ohta on Mon May 19 18:20:02 2025
    On Sun, May 18, 2025 at 08:13:17PM +0900, K.Ohta wrote:
    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.

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

    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.

    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.

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

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

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Grohne@21:1/5 to K.Ohta on Thu May 22 23:20:01 2025
    On Wed, May 21, 2025 at 09:49:52PM +0900, K.Ohta wrote:
    *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).

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

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

    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).

    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.

    I hope we can skip all of this.

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

    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.

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

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

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

    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?

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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)