chroot: failed to run command ‘/bin/bash’: No such file or directory

Question

When I run the chroot command an error is given:

failed to run command ‘/bin/bash’: No such file or directory 

Answer 1

This error means that there is no /bin/bash directory inside chroot. Make sure you point it to where bash (or other shell's) executable is in chroot directory.

If you have /mnt/somedir/usr/bin/bash then execute chroot /mnt/somedir /usr/bin/bash.

Apart from the above, you also need to add libc directory dependencies, as mentioned in the answer here.

Answer 2

I had /bin/bash inside chrooted directory, but I didn't have /lib and /lib64 inside it. The message from chroot could be more descriptive. "no such file or directory" really means "I can't run this...".

/bin/bash depends of course on libc, ld-linux, libdl etc., you can use ldd /bin/bash to see which libraries it requires.

1. You can mount -o bind these directories under chroot
2. Or you can copy these libraries to chroot, if you don't trust the chrooted env to not corrupt them, like so:

   cp -a /usr rootfs/
   cp -a /lib rootfs/
   cp -a /lib64 rootfs/
   

Answer 3

chroot tries to start the shell that is set in your $SHELL environment variable by default, but it looks for it in your new root dir, which seems not to contain /bin/bash, so it cannot start.

You can tell chroot to start another program inside the new root by simply adding it as a parameter:

chroot /your/new/root /bin/foo --options...

Note that the path of the command is interpreted inside your new root, so in this example the called program is in fact in /your/new/root/bin/foo

Answer 4

In case you are doing a cross compilation you need to use qemu simulator which can run /mnt/somedir/bin/bash. Below are the steps for armhf cross compilation. Steps for other architectures should be similar.

1. First install qemu-user-static

sudo apt-get install qemu-user-static

2. Then copy the 'qemu-arm-static' binary into the chroot directory

sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/

Once you copy the qemu-arm-static into the /mnt/usr/bin you will be able to do chroot.

Check this out for more details: https://blog.lazy-evaluation.net/posts/linux/debian-armhf-bootstrap.html

Answer 5

I was getting the same error when trying to ssh to a chrooted account on a remote server. In my case, I was missing the following file in the remote lib64 directory. Server is Centos6.9

ld-linux-x86-64.so.2

It was fixed by executing the following:

cp /lib64/ld-linux-x86-64.so.2 /secure/jail/lib64/

Answer 6

Make it sure /lib is a symlink to usr/lib.

In my case, in ubuntu 22.04, after I tried to checkinstall vmwareplayer, the /lib got messed up when it failed saying there was a new version installed. Then I guess that when checkinstall tried to revert the changes, it (or vmwareplayer installer) messed up /lib.

So the /lib was not a symlink to usr/lib, it was actually a real empty folder!

That also caused a serious problem making ubuntu22.04 unbootable because of /sbin/init or /etc/init not found: run-init: can't execute '/sbin/init': No such file or directory and /etc/init permission denied
It caused also kernel panic attempted to kill init on boot time.

Answer 7

I was getting this error as well, but the solution turned out to be much simpler for me than many of the above answers. I was simply chroot'ing to the wrong directory.

On modern versions of the product my team supports, the product chroot is /opt/productname, hence we use sudo chroot /opt/productname.

On very old versions of the product, the product chroot is named /opt/productname-x-y-z. ie it has the version appended to the product chroot name.

So sudo chroot /opt/productname on the old system, gave me the "chroot: command failed ... " error. On the old system, /opt/productname existed, but was not actually a chroot directory.

Answer 8

you need to run ldd against bash ldd $(which bash), then you might find a missing dependency, for example if you didn't mount/copy lib64, for 64 systems, it will through this error.

Answer 9

Something no one has mentioned yet, if the goal is not to keep copies of libraries you locate with ldd. When you build busybox it respects LDFLAGS=--static per their FAQ. This will build all necessary libraries into your binaries. This does increase the size of the binaries, but... you'd need most of this disk space to store what you're locating with ldd anyway.

Note that you may still need to copy your c library (libc.so.6), core math library (libm.so.6), namespace resolution library (libresolv.so.2), and kernel library (in my case, since I am using a raspberry pi, ld-linux-armhf.so.3) . You can use the ldd tool as directed in other answers on your static busybox binary to discover whether this is the case.

These may in turn depend on other libraries. To discover whether this is the case you can use the file tool. I am using the full path to raspberry pi's libm.so.6 as an example :

file /chroot/lib/arm-linux-gnueabihf/libm.so.6

In my case, since ARM processors need many libraries, I copied my entire arm-linux-gnueabihf folder into my lib folder, allowing me to access my chroot.

Answer 10

1. Run ldd /bin/bash to see dependences. Wiil reply like follows:

linux-vdso.so.1 (0x00007ffd057eb000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f83183bc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f83183b6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f83181c4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8318536000)

2. Then for each run diff. Like diff /lib/x86_64-linux-gnu/libtinfo.so.6 /mnt/lib/x86_64-linux-gnu/libtinfo.so.6 etc. (Change /mnt to your mount path.)

   Also run diff for the bash, like diff /usr/bin/bash /mnt/usr/bin/bash.

   Skip linux-vdso.so.1 because it inserted into kernel.

3. If will found differences then make replace these by files from Live CD.

4. Also check that the symlink links /lib, /lib32, /lib64 lead to the correct directories (to /usr/lib etc).

Answer 11

sudo nano /etc/passwd 

After that, look for the user that gives you the problems and verify that in front of / bin / bash there are no spaces or any other character, in case of chroor, verify the root user.

nano can be replaced by any text editor.

Answer 12

Shortcut command to copy all the lib that's require by a command for this example /bin/bash (You have to replace {CHROOT PATH} with the path of your chroot)

the file usually paste into lib lib64 depends on the /bin/bash requirement

list="$(ldd /bin/bash | egrep -o '/lib.*\.[0-9]')"
for i in $list; do cp -v --parents "$i" "{CHROOT PATH}"; done

Answer 13

Since the root has been changed the relative links to bash and other libraries no longer work. You need to copy those libraries into your DIR_TO_CHROOT

1. Copy bash

    mkdir /DIR_TO_CHROOT/bin
    cp /bin/bash /DIR_TO_CHROOT/bin # copy bash
    

2. Copy bash's dependencies
   • create lib and lib64 to host these dependencies

     mkdir /DIR_TO_CHROOT/lib{,64} # create lib and lib64 folders
     

   • Find the exact dependencies needed (example output from my installation):

     ldd /bin/bash
     
     linux-vdso.so.1 (0x00007fffa89d8000)
     libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f6fb8a07000)
     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6fb8803000)
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6fb8412000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f6fb8f4b000)
     

   • So in my own case, I copy the dependencies like this:

     cp /lib/x86_64-linux-gnu/libtinfo.so.5 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 /DIR_TO_CHROOT/lib #lib
     cp /lib64/ld-linux-x86-64.so.2 /DIR_TO_CHROOT/lib64 #lib64
     

Now you should be able to use bash

chroot /my-new-root bash

Answer 14

The bash elf is not available in /bin, /usr/bin/ etc.

cp -rf --preserve=links  /usr/bin/* myroot/usr/bin/; cp --preserve=links  -rf /lib64/*  myroot/lib64/;..

copy all libraries and ELFs.