[arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory

[David C. Rankin]

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.