# ls -l /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libtinfo.so.5': No such file or directory

# ls -l /mnt/lib/x86_64-linux-gnu/libdl.so.2
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libdl.so.2': No such file or directory

# ls -l /mnt/lib/x86_64-linux-gnu/libc.so.6
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libc.so.6': No such file or directory

# ls -l /mnt/bin/bash
-rwxr-xr-x 1 root root 1099016 May 15  2017 /mnt/bin/bash

Doesnt look right. Dont know why they are missing. I guess I will have to find them and link them back or something.

I just verified that in order to chroot into a directory /BLAH you only need 5 files:

/BLAH/bin/bash
/BLAH/lib/x86_64-linux-gnu/libtinfo.so.5
/BLAH/lib/x86_64-linux-gnu/libc.so.6
/BLAH/lib/x86_64-linux-gnu/libdl.so.2
/BLAH/lib64/ld-linux-x86-64.so.2

So, getting tedious: check that the files concerned are not links that points out of /mnt:

# ls -l /mnt/lib64/ld-linux-x86-64.so.2
# ls -l /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
# ls -l /mnt/lib/x86_64-linux-gnu/libdl.so.2
# ls -l /mnt/lib/x86_64-linux-gnu/libc.so.6
# ls -l /mnt/bin/bash

The first one in particular might point to /lib/x86_64-linux-gnu/ld-2.24.so (or something) and maybe /mnt/lib/x86_64-linux-gnu/ld-2.24.so (or something) is missing. That could explain why it "looks right" in the prior checks, without actually being right under chroot.

# ls -lL /mnt/lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 153288 Feb  6  2019 /mnt/lib64/ld-linux-x86-64.so.2

Maybe I should just reinstall. Maybe that installation has been hit by a god-particle.

It feels "rude" to ask, but one of the main causes for this problem is simply that one attempts to run with a 64 bit kernel inside a 32 bit OS file system. I missed on confirming before, that you have:

# ls -lL /mnt/lib64/ld-linux-x86-64.so.2

Let's get past this one ....

but I can cd into /mnt and do an ls and it works, so it must be a problem with chroot itself.

Again" Remember, these are Vanilla installs. The only thing that has been done after install is apt update & apt upgrade.
That is it.

I want to use Devuan on my rackservers and is currently testing it. I like it very much as I got rid of all the enormous systemD related problems by using it, but chroot is unfortunately crucial to work.
Does it actually work on anyone elses latest Devuan install ? I did list my distro details in an earlier post for reference

I guess you verified that the libs are available:

# ls -lL /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
# ls -lL /mnt/lib/x86_64-linux-gnu/libdl.so.2
# ls -lL /mnt//lib/x86_64-linux-gnu/libc.so.6

Does something else work? Eg
# chroot /mnt ls

... it's gradually rising to be a "peculiar" problem ...

# ldd /mnt/bin/bash
    linux-vdso.so.1 (0x00007ffc7798e000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fda49c9b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fda49a97000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda496f8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fda49ec5000)

For the record remember these are vanilla installations of Devuan.
No alterations. Both are identical

# cat /etc/*lease*
PRETTY_NAME="Devuan GNU/Linux ascii"
NAME="Devuan GNU/Linux"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

# cat /proc/version
Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19)

/mnt/bin/bash

When that looks fine, your problem have risen to the level of "intricate"

The next is to confirm its dynamically linked libraries, which starts by checking which they are in the current root, and then verify that they are all present within /mnt. Use ldd /mnt/bin/bash.

/dev/sdb6       11468016 2111548   8754204  20% /mnt

root@blinc:~# ls -l /mnt/bin/bash
-rwxr-xr-x 1 root root 1099016 May 15  2017 /mnt/bin/bash

I can even execute /mnt/bin/bash
and it complees without error.
Perfectly working.

I suggest you investigate this directly after the first mount command, which makes the file system of sda6 available under /mnt.

All the other commands (except chroot) are just extra noise here, and they serve no purpose for you being able to change the root file system for a process.

So the investigation sequence would be two commands, with the first one optional (if you have doen it already):

# mount /dev/sda6 /mnt
# ls -l /mnt/bin/bash

Consistently with the chroot error you may get the result:

ls: cannot access '/mnt/bin/bash': No such file or directory

or you may get something else, which in any case should provide something for understanding the chroot error report.

Later, when you have sorted out your chroot problem, you return to also use the other commands, when/if you need access to those virtual file system components.

BTW, that error message about /bin/bash must be a bug with chroot. /bin/bash clearly exists.
It is a bug misreporting an error now for years and they never fix it.

In my case system is /dev/sdb3 and target to chroot to is /dev/sdb6

root@blinc:~# mount /dev/sdb6 /mnt
root@blinc:~# mkdir -p /mnt/boot/efi 
root@blinc:~# mount /dev/sdb3 /mnt/boot/efi
root@blinc:~# mount --bind /dev /mnt/dev
root@blinc:~# mount --bind /proc /mnt/proc
root@ginc:~# mount --bind /sys /mnt/sys
root@blinc:~# chroot /mnt 
chroot: failed to run command ‘/bin/bash’: No such file or directory

Note: These are fresh unaltered Devuan installs.

Are you sure about your EFI partition? It's generally (always?) partition 1...

Not sure you need to mount the EFI partition, depending on what you're chrooting to do - I always mount it because I'm often reinstalling grub or something like that...

root@blinc:~# mount /dev/sdb6 /mnt
root@blinc:~# mkdir -p /mnt/boot/efi 
root@blinc:~# mount /dev/sdb3 /mnt/boot/efi
root@blinc:~# mount --bind /dev /mnt/dev
root@blinc:~# mount --bind /proc /mnt/proc
root@ginc:~# mount --bind /sys /mnt/sys
root@blinc:~# chroot /mnt 
chroot: failed to run command ‘/bin/bash’: No such file or directory

Note: These are fresh unaltered Devuan installs.
also, if you dont give the command field to chroot then it assumes that bash is in /bin/bash you give the command argument if bash is somewhere else than that.
In this case bash IS in /bin/bash. so both our chroot commands are basically the same.

Somehow my usual chroot tricks dont work on Devuan.

I have two Devuan installations on the same disk.
One on /dev/sdb3 and another on /dev/sdb6

I want to chroot devuan on /dev/sdb6 while I am in devuan on /dev/sdb3

While I am root user in Devuan on /dev/sdb3 I do.

mount /dev/sdb6 /sdb6
mount -t proc none /sbd6/proc
mount -t proc none /sdb6/proc
mount --rbind /sys /sdb6/sys
mount --rbind /dev /sdb6/dev
chroot /sdb6 /bin/bash

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

Why doesnt this work in Devuan ?
It worked on Debian

I have never added '/bin/bash' to the chroot command - I just use chroot (location of mounted system), and have never had a problem.

My formula goes like this (system on sda5):

sudo mount /dev/sda5 /mnt  

sudo mkdir -p /mnt/boot/efi          
sudo mount /dev/sda1 /mnt/boot/efi   

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

sudo chroot /mnt  

It's never failed me (yet).

And..
# ls /bin/chroot
ls: cannot access '/bin/chroot': No such file or directory

# whereis chroot
chroot: /usr/sbin/chroot /usr/share/man/man8/chroot.8.gz

So the commands you posted are for a completely different system than Devuan.