Thomas Southerland (HE12025-07-20):

pool then chroot into the broken file system.

At that point, apt update and apt upgrade should work.

No, they should not. Booting on another system and chrooting is for when
the system does not want to boot or does not want to let you in, but it
still requires running programs: if the issue is that the system does
not want to run programs, chroot will not convince it.

What is needed is to extract manually enough of the shared libraries.

Regards,

--
Nicolas George

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

On Sun, Jul 20, 2025 at 10:52:36 -0400, Timothy M Butterworth wrote:

On Sun, Jul 20, 2025 at 7:23 AM Max Nikulin <manikulin@gmail.com> wrote:

On 20/07/2025 13:22, Tom Dial wrote:

unable to install new version of '/lib64/ld-linux-x86-64.so.2': No
such file or directory

try:
"sudo apt update"
"sudo apt purge ld-linux"
"sudo apt install ld-linux"

That isn't even a valid package name, let alone a sensible recipe.

If ld-linux *were* a standalone package, then purging it would almost
certainly cause every dynamically linked command on your system to
break. That would definitely include sudo and apt.

The most likely solution here is going to be something like:

1) Boot from some other medium.
2) Mount the affected file system somewhere.
3) cd (NOT chroot) into the affected file system's /tmp directory.
4) Extract a libc6 package of the appropriate arch and version.
5) Move the files into their correct locations.
6) chroot into the affected file system's / directory.
7) Run /sbin/ldconfig.
8) Exit the chroot, cd out of the affected system, and unmount it.
9) Reboot into the affected system to test it.
10) If all seems well, reinstall the libc6 package via apt or dpkg.
Just to make sure. (Note: this must be a single reinstall step,
not a purge followed by an install.)

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

Relatively quick repair should be feasible.
So ... multi-arch? Is this native amd64 + i386 (I'm
guessing/presuming), or ... is that vice versa?
I'm inclined to similarly break a VM, and then fix it ... shouldn't be too hard.
Anyway, main/primary architecture would be the most critical.
I'll poke a bit on VM, thoroughly clobber libc6 ... then fix it. :-)
Also wouldn't expect that to break along the way within stable,
but perhaps 12.1 --> 12.11 with multiarch, you tripped over some bug,
or maybe some
other issue triggered the problem.

On Sat, Jul 19, 2025 at 11:48 PM Tom Dial <tddial@comcast.net> wrote:

In updating a Bookworm installation from 12.1 to 12.11 I have hit a brick wall during upgrade of libc6 and libc6:i386. The update appeared normal until the upgrade of libc6:i386 (apology offered for the wrap):
------
Preparing to unpack .../20-libc6_2.36-9+deb12u10_i386.deb ...
De-configuring libc6:amd64 (2.36-9+deb12u1), to allow configuration of libc6:i386 (2.36-9+deb12u10) ...
Unpacking libc6:i386 (2.36-9+deb12u10) over (2.36-9+deb12u1) ...
Preparing to unpack .../21-libc6_2.36-9+deb12u10_amd64.deb ...
Unpacking libc6:amd64 (2.36-9+deb12u10) over (2.36-9+deb12u1) ...

dpkg: error processing archive /tmp/apt-dpkg-install-UE9ugP/21-libc6_2.36-9+deb12u10_amd64.deb (--unpack):
unable to install new version of '/lib64/ld-linux-x86-64.so.2': No such file or directory

dpkg (subprocess): unable to execute new libc6:amd64 package post-removal script (/var/lib/dpkg/tmp.ci/postrm): No such file or directory

dpkg: error while cleaning up:
new libc6:amd64 package post-removal script subprocess returned error exit status 2

dpkg (subprocess): unable to execute rm command for cleanup (rm): No such file or directory

dpkg: error while cleaning up:
rm command for cleanup subprocess returned error exit status 2

Errors were encountered while processing:
/tmp/apt-dpkg-install-UE9ugP/21-libc6_2.36-9+deb12u10_amd64.deb
------
At this point, the shell (bash) continues to run, but all commands not built in fail with a message like

failed to run command ‘/usr/bin/ls’: No such file or directory

presumably because ld-linux-x86-64.so.2 is unavailable to load and link necessary shared libraries.

I have set up the failed image in a chroot environment, and tried replacing ld-linux-x86-64.so.2 in what I assume is its correct location -

/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

This allows bash to start, but other commands still fail, now with segmentation faults:

root@recovery:~# chroot /mnt /bin/bash --login
bash: [: : integer expression expected
root@recovery:/# ll
Segmentation fault
root@recovery:/# pwd
/
root@recovery:/# hostname
Segmentation fault
root@recovery:/# exit
logout
root@recovery:~# pwd
/root
root@recovery:~# hostname
recovery
root@recovery:~#

I would be grateful for suggestions for repair of the exiting image. The filesystem is ZFS and I havce two full snapshots: immediately after the original Bullseye installation and immediately after the upgrade to Bookworm, and have enough backups to

restore user data from either point along with information to reinstall all packages. A quick repair would be nice, but if it's too involved or uncertain, I can reinstall.

Thanks in advance for any suggestions.

Tom Dial

a) roll back to the initial install (Bullseye) and update/upgrade from that; or
b) clear the disk and reinstall everything

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

Proceeded to seriously break system using rm on libc6:amd64 files.
rmed (or attempted):
all files of type ordinary file in libc6:amd64 package (per dpkg -L)
plus symbolic links resolving to such,
and putting as very last in that sequence,
from information from ldd rm
the overlapping files between the two and ordering within
that last bit, first
file(s) of type symbolic link resolving to files of type ordinary file,
then files of type ordinary file.
And yes, that of course seriously broke the system. :-)

And from a "recovery" environment (actually physical host of the VM in
this case, but regardless), use ar, xz, and tar to restore the files
from the package (and avoiding the chroot complications of too much
missing under target directory for most things to function under
a chroot there).:
With the target filesystem(s) mounted rw under mnt
# ar p \
/var/cache/apt/archives/libc6_2.36-9+deb12u10_amd64.deb data.tar.xz |
xz -d | (umask 022 && cd mnt && tar -xf -)
Then unmounted, booted that (VM) host, and for good measure did:
# apt-get install --reinstall libc6:amd64
Most notably so that would also cover running and pre/post scripts that
might be needed, and also getting the package state appropriately set to cleanly installed in the APT database. All seems fine after that.

On Sun, Jul 20, 2025 at 10:12 PM Michael Paoli
<michael.paoli@berkeley.edu> wrote:

Relatively quick repair should be feasible.
So ... multi-arch? Is this native amd64 + i386 (I'm
guessing/presuming), or ... is that vice versa?
I'm inclined to similarly break a VM, and then fix it ... shouldn't be too hard.
Anyway, main/primary architecture would be the most critical.
I'll poke a bit on VM, thoroughly clobber libc6 ... then fix it. :-)
Also wouldn't expect that to break along the way within stable,
but perhaps 12.1 --> 12.11 with multiarch, you tripped over some bug,
or maybe some
other issue triggered the problem.

On Sat, Jul 19, 2025 at 11:48 PM Tom Dial <tddial@comcast.net> wrote:

In updating a Bookworm installation from 12.1 to 12.11 I have hit a brick wall during upgrade of libc6 and libc6:i386. The update appeared normal until the upgrade of libc6:i386 (apology offered for the wrap):
------
Preparing to unpack .../20-libc6_2.36-9+deb12u10_i386.deb ... De-configuring libc6:amd64 (2.36-9+deb12u1), to allow configuration of libc6:i386 (2.36-9+deb12u10) ...
Unpacking libc6:i386 (2.36-9+deb12u10) over (2.36-9+deb12u1) ...
Preparing to unpack .../21-libc6_2.36-9+deb12u10_amd64.deb ...
Unpacking libc6:amd64 (2.36-9+deb12u10) over (2.36-9+deb12u1) ...

dpkg: error processing archive /tmp/apt-dpkg-install-UE9ugP/21-libc6_2.36-9+deb12u10_amd64.deb (--unpack):
unable to install new version of '/lib64/ld-linux-x86-64.so.2': No such file or directory

dpkg (subprocess): unable to execute new libc6:amd64 package post-removal script (/var/lib/dpkg/tmp.ci/postrm): No such file or directory

dpkg: error while cleaning up:
new libc6:amd64 package post-removal script subprocess returned error exit status 2

dpkg (subprocess): unable to execute rm command for cleanup (rm): No such file or directory

dpkg: error while cleaning up:
rm command for cleanup subprocess returned error exit status 2

Errors were encountered while processing:
/tmp/apt-dpkg-install-UE9ugP/21-libc6_2.36-9+deb12u10_amd64.deb
------
At this point, the shell (bash) continues to run, but all commands not built in fail with a message like

failed to run command ‘/usr/bin/ls’: No such file or directory

presumably because ld-linux-x86-64.so.2 is unavailable to load and link necessary shared libraries.

I have set up the failed image in a chroot environment, and tried replacing ld-linux-x86-64.so.2 in what I assume is its correct location -

/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

This allows bash to start, but other commands still fail, now with segmentation faults:

root@recovery:~# chroot /mnt /bin/bash --login
bash: [: : integer expression expected
root@recovery:/# ll
Segmentation fault
root@recovery:/# pwd
/
root@recovery:/# hostname
Segmentation fault
root@recovery:/# exit
logout
root@recovery:~# pwd
/root
root@recovery:~# hostname
recovery
root@recovery:~#

I would be grateful for suggestions for repair of the exiting image. The filesystem is ZFS and I havce two full snapshots: immediately after the original Bullseye installation and immediately after the upgrade to Bookworm, and have enough backups to

restore user data from either point along with information to reinstall all packages. A quick repair would be nice, but if it's too involved or uncertain, I can reinstall.

Thanks in advance for any suggestions.

Tom Dial

a) roll back to the initial install (Bullseye) and update/upgrade from that; or
b) clear the disk and reinstall everything

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