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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
