You are not logged in.
Pages: 1
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
Last edited by devuanuser (2019-09-02 20:19:25)
Offline
Obvious: where does /bin/bash lead you? Is it a sym-link to dash or another shell? And why are you mounting proc twice? (typo, I assume )
These are the commands Funtoo uses to chroot into a new install:
mount -t proc none proc
mount --rbind /sys sys
mount --rbind /dev dev
env -i HOME=/root TERM=$TERM /bin/chroot . bash -l
HTH!
Offline
Hi thanks.
This doesnt work at all sorry, .mount -t proc none proc can never work
'Yes I copied it double.from my terminal
/bin/bash is command to be executed in target installation.
Used to work flawlessly.
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.
Last edited by devuanuser (2019-09-02 21:07:22)
Offline
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/sdb6I 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/bashI now get
chroot: failed to run command ‘/bin/bash’: No such file or directoryWhy 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).
Online
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.
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.
Last edited by devuanuser (2019-09-02 21:39:39)
Offline
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 directoryNote: 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...
Online
This pc dont have efi enabled bios, it is legacy..
Yes you guessed right, I have to run grub on that partition.
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.
Last edited by devuanuser (2019-09-02 21:48:13)
Offline
Apparently sda6 does not contain a complete file system, and in particular it doesn't have an executable program /bin/bash.
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.
Offline
Nope the file system is intact and it has an executable /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.
Last edited by devuanuser (2019-09-02 22:11:27)
Offline
That looks good. I would then confirm the executable by running it
/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.
Offline
I already confirmed that # /mnt/bin/bash executes without returning an error in my previous posts.
# 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)
Last edited by devuanuser (2019-09-03 02:18:24)
Offline
Yes, it *should* work. But it doesn't
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 ...
Offline
# chroot /mnt ls
chroot: failed to run command ‘ls’: No such file or directory
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
Last edited by devuanuser (2019-09-03 08:49:09)
Offline
Hmm. The problem obviously has little to do bash as such, but with the attempt to run a dynamic 64bit binary. You are sure the sda6 OS is 64 bit as well? For example, that there is a /lib64 directory?
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 ....
Offline
You can be rude, sometimes good and clever people make stupid mistakes, but so far I didnt.
# 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.
Last edited by devuanuser (2019-09-03 09:52:50)
Offline
Interesting. Possibly a reinstall would make your problem go away; it tends to work on Windows, so why not with Linux ;D
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.
Offline
# ls -l /mnt/lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 32 Jan 14 2018 /mnt/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.24.so
# 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.
Last edited by devuanuser (2019-09-03 14:12:01)
Offline
Pages: 1