apt-get /lib/ld-linux.so.3 deletion screwup disaster :-(
I am not happy :-(
My i.MX53 quick start board had been happily running with an
/etc/apt/sources.list like:
deb http://ftp.debian-ports.org/debian unstable main
deb http://ftp.debian-ports.org/debian unreleased main
deb-src http://ftp.gr.debian.org/debian unstable main
deb http://incoming.debian-ports.org/buildd unstable main
deb-src http://incoming.debian-ports.org/buildd unstable main
I think that was included in an armhf root fs image that Konstantinos
Margaritis gave us, and not changed by me. This was last used properly in
late 2011.
Today I wanted to install something, but I got some 404s from apt-get
update. So I changed it over to the more conventional lines that I've been
using on another newer armhf system:
deb http://ftp.uk.debian.org/debian sid main
deb-src http://ftp.uk.debian.org/debian sid main
Then I did an apt-get update, and an apt-get install, and it decided to
replace my libc. This seems to have barfed mid-way with some perl spewage
related to locales:
[snip]
Preparing to replace libc6-dbg 2.13-7 (using
.../libc6-dbg_2.13-38_armhf.deb) ...
Unpacking replacement libc6-dbg ...
Preparing to replace libc-bin 2.13-7 (using .../libc-bin_2.13-38_armhf.deb) ...
Unpacking replacement libc-bin ...
Processing triggers for ccache ...
Updating symlinks in /usr/lib/ccache ...
Processing triggers for man-db ...
Can't exec "locale": No such file or directory at
/usr/share/perl5/Debconf/Encoding.pm line 16.
Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at
/usr/share/perl5/Debconf/Encoding.pm line 17.
Setting up libc-bin (2.13-38) ...
Installing new version of config file /etc/bindresvport.blacklist ...
(Reading database ... 30538 files and directories currently installed.)
Preparing to replace libc6 2.13-7 (using .../libc6_2.13-38_armhf.deb) ...
Can't exec "locale": No such file or directory at
/usr/share/perl5/Debconf/Encoding.pm line 16.
Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at
/usr/share/perl5/Debconf/Encoding.pm line 17.
Unpacking replacement libc6 ...
dpkg (subprocess): unable to execute rm command for cleanup (rm): No such
file or directory
dpkg: error while cleaning up:
subprocess rm cleanup returned error exit status 2
Could not exec dpkg!
E: Sub-process /usr/bin/dpkg returned an error code (100)
Nauseatingly, and IMHO inexcusably, it chose to crash while the system was
in an apparently vulnerable state mid-update. All commands in the shells
that I had open said something like:
$ ls
-bash: /bin/ls: No such file or directory
I am sure I once saw a web page that explained how to do useful stuff using
only bash builtins. For example, "echo *" instead of ls and "read L < foo;
echo $L" instead of cat. I hoped that I would never need it.
I eventually discovered that things would run if I invoked the dynamic
linker directly:
# /lib/ld-linux-armhf.so.3 /bin/ls
I was then able to establish that my existing executables want a dynamic
linker called /lib/ld-linux.so.3, while I now have only
/lib/ld-linux-armhf.so.3 . By symlinking the latter to the former, the
system is apparently functional again.
So what is the root problem here? Has there been some significant shift in
armhf (multiarch?) that renamed the dynamic linker? Should apt-get have
coped with this transition (or stopped me from trying?)? Or should it have
installed e.g. a symlink, but failed due to the perl locale spewage visible
in the original error?
Any advice would be most welcome before I try anything else.
ALSO: does anyone have any experience with e.g. filesystem-level rollback to
recover from things like this?
Thanks,
Phil.
Reply to: