On 03/06/2013 08:24 PM, Ross Hamblin wrote:
On 07/03/13 14:32, David C. Rankin wrote:
Guys,
Attempting to fix the test box that updating left unable to boot, I cannot chroot to fix the system. I've booted from the install medium and done the normal mount of the existing system under /mnt:
mount /dev/sda6 /mnt mount /dev/sda5 /mnt/home mount /dev/sda8 /mnt/boot mount -o bind /dev /mnt/dev mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys
All files appear in their proper place under /mnt. However, attempting to create the chroot fails:
cd /mnt chroot /mnt /bin/bash
chroot: failed to run command '/bin/bash': No such file or directory
/bin/bash is in the new location /usr/bin/bash (moved from /bin/bash by the update) with with a proper symlink in /mnt/bin/bash pointing to ../usr/bin/bash
This if the first time I've ever had difficulty chrooting a system. I suspect that this is caused by the last update that pulled in systemd which left the system unbootable. Anyone know what could be causing the chroot failure? I've tried explicitly pointing the chroot to ./usr/bin/bash, etc... and tried it without any executable specified. Regardless, I get the same "No such file or directory".
Thanks in advance for any help or link you can provide.
It's been a while now but ISTR this message when chroot from 32 bit host and 64 bit target, or maybe it was vice versa.
HTH Ross.
All, The problem with the update (11/20/12 -> 2/5/13) appears to be that the update of filesystem (or something) removed the /lib -> /usr/lib link from the / directory causing much of the update to fail. This apparently is a problem for boxes that haven't been updated in a few months. The last system update before the one on 2/5/13 was on 11/20/12. The pacman.log contains hints of where the problem began. Specifically, from the pacman.log file I have: [2013-02-05 23:45] synchronizing package lists [2013-02-05 23:45] starting full system upgrade [2013-02-05 23:53] removed eject (2.1.5-7) [2013-02-05 23:53] userdel: user dbus is currently used by process 452 [2013-02-05 23:53] groupdel: cannot remove the primary group of user 'dbus' [2013-02-05 23:53] removed dbus-core (1.6.4-1) <snip> (don't know if this is important -- repeated twice in log) [2013-02-05 23:53] /usr/bin/gconftool-2: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory [2013-02-05 23:53] /usr/bin/gconftool-2: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory <snip> [2013-02-05 23:53] upgraded linux-api-headers (3.5.1-1 -> 3.7.4-1) [2013-02-05 23:53] upgraded tzdata (2012e-1 -> 2012j-1) [2013-02-05 23:53] warning: /etc/gshadow installed as /etc/gshadow.pacnew [2013-02-05 23:53] warning: /etc/passwd installed as /etc/passwd.pacnew [2013-02-05 23:53] warning: /etc/group installed as /etc/group.pacnew [2013-02-05 23:53] warning: /etc/fstab installed as /etc/fstab.pacnew [2013-02-05 23:53] warning: /etc/shadow installed as /etc/shadow.pacnew [2013-02-05 23:53] upgraded filesystem (2012.8-1 -> 2013.01-3) [2013-02-05 23:53] warning: /etc/locale.gen installed as /etc/locale.gen.pacnew [2013-02-05 23:53] call to execv failed (No such file or directory) [2013-02-05 23:53] upgraded glibc (2.16.0-4 -> 2.17-3) [2013-02-05 23:54] call to execv failed (No such file or directory) [2013-02-05 23:54] upgraded bash (4.2.037-1 -> 4.2.042-3) [2013-02-05 23:54] call to execv failed (No such file or directory) I don't know if it was the filesystem package or not, but after the filesystem install, there are many of the "call to execv failed (No such file or directory)" errors noted. After working with the chroot error a bit I stumbled across the fact that link for /lib was missing. After manually creating the link again, chroot worked like a champ. I don't know how much of the system got borked as a result, but a fresh pacman -Syu complete normally. I have not finished examining the system yet, so I have not attempted to boot to the new kernel. I will have to go through and verify the grub legacy config before I reboot. I'll report back after I have had an opportunity to test the box. Thank you to those that responded. -- David C. Rankin, J.D.,P.E.