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 <tdd...@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 >
