In the process of trying to rescue an unbootable Debian Jessie system, I get the following error when trying to chroot:
chroot: failed to run command ‘/bin/bash’: No such file or directory
I have been googling around and it's supposedly related to a 64bit/32bit clash (chrooting from a 32bit into 64bit or vis a versa), yet I don't see how that could apply here since I am rescuing a 64bit system with a 64bit live-hybrid-Debian-USB-stick.
/bin/bash is in the chroot directory and so are the library depenencies, as per ldd.
Does anyone have an idea what is causing the error?
Below are my mount points, and an ls:
# mount |grep mnt
/dev/mapper/centos_vh200-root on /mnt/vh2 type ext4 (rw,relatime,data=ordered)
/dev/sda1 on /mnt/vh2/boot type ext4 (rw,relatime,data=ordered)
none on /mnt/vh2/proc type proc (rw,relatime)
devtmpfs on /mnt/vh2/dev type devtmpfs (rw,nosuid,size=10240k,nr_inodes=414264,mode=755)
sys on /mnt/vh2/sys type sysfs (rw,relatime)
# ls -l /mnt/vh2/bin/bash
-rwxr-xr-x 1 root root 1029624 Nov 12 2014 /mnt/vh2/bin/bash
This is ldd output for bash:
# ldd /mnt/vh2/bin/bash
linux-vdso.so.1 (0x00007ffd49bcc000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007fad99f1a000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fad99cf0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fad99aec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fad99743000)
/lib64/ld-linux-x86-64.so.2 (0x00007fad9a13f000)
Terminal session:
# mount /dev/centos_vh200/root /mnt/vh2
# mount /dev/sda1 /mnt/vh2/boot/
# mount -t proc none /mnt/vh2/proc/
# mount -o bind /dev /mnt/vh2/dev/
# mount -t sysfs sys /mnt/vh2/sys/
# chroot /mnt/vh2/ /bin/bash
chroot: failed to run command ‘/bin/bash’: No such file or directory
ldd /mnt/vh2/bin/bash is done outside chroot so it finds your live system libraries. Look for libraries in /mnt/vh2/ not in /.
Related
I am using Buildroot to build an initramfs image for my IMX Board. On the board, I run a custom Linux 4.19.35 Linux kernel (4.19.35-gexxxxxx) and a custom U-Boot bootloader. Hence, do not require these from Buildroot. My use case is only the rootfs.cpio (initramfs) image that gets built.
I am able to load the above initramfs into memory and execute my custom init and post-init scripts. However, I am unable to spawn an interactive shell. On reaching the command /bin/sh in the init script, I am greeted with a shell prompt but it seems that the serial console is not registering any keyboard inputs. Note that all other shell utilities and commands are executed just fine, but only when they are run in a script. Since one of my objectives is to have a minimal image, I am using busybox (1.32.0).
This gets even more confusing when I run the same initramfs along with the kernel image that is generated by buildroot. In this case, I do get an interactive shell prompt and I am able to enter my input like in a regular terminal.
I am suspecting that this might happen because of the different kernels. The buildroot kernel image is 4.19.35 but the kernel I use is 4.19.35-gexxxxx. However, I am not sure how the initramfs might be dependent on the kernel version string.
Any directions on what might be going wrong would be very helpful.
Edit 1: Below is my init code:
#!/bin/sh
/bin/mount -t devtmpfs devtmpfs /dev
export PATH=/sbin:/usr/sbin:/bin:/usr/bin
[ -d /dev ] || mkdir -m 0755 /dev
[ -d /root ] || mkdir -m 0700 /root
[ -d /sys ] || mkdir /sys
[ -d /proc ] || mkdir /proc
[ -d /tmp ] || mkdir /tmp
[ -d /run ] || mkdir /run
mkdir -p /dev/pts
mkdir -p /var/lock
/bin/mount -t sysfs -o nodev,noexec,nosuid sysfs /sys
/bin/mount -t proc -o nodev,noexec,nosuid proc /proc
/bin/mknod -m 666 /dev/ttyS0 c 4 64
/bin/mknod -m 666 /dev/ttyS0 c 4 64
/bin/mknod -m 622 /dev/console c 5 1
/bin/mknod -m 666 /dev/null c 1 3
/bin/mknod -m 666 /dev/tty c 5 0
/bin/mknod -m 666 /dev/zero c 1 5
/bin/mknod -m 666 /dev/ttymxc3 c 5 1
/bin/sh # --------------------> Spawning a shell
Try using a 5v serial adapter instead of 3.3v - with the lower voltage, you can still see what it's sending, but your adapter doesn't get heard by the device.
I am trying to figure out why if I don't need to do this step
(Ubuntu before wily only) Add yourself to the fuse group, then log out and back in:
sudo usermod -a -G fuse $USER
exit
Then why can't I write to files; I keep getting the following error:
Using mount point: /mnt/c/Users/russe/Documents/gstorage
Opening GCS connection...
Opening bucket...
Mounting file system...
daemonize.Run: readFromProcess: sub-process: mountWithArgs: mountWithConn: Mount: mount: running fusermount: exit status 1
stderr:
fusermount: fuse device not found, try 'modprobe fuse' first
I am using Ubuntu (on Windows App Store).
Even running:
sudo mount -t gcsfuse -o implicit_dirs,allow_other,uid=1000,gid=1000,key_file=/mnt/c/Users/russe/Documents/RadioMedia-ba86f56a2aa6.json radiomediapod
cast gstorage
had an error:
Calling gcsfuse with arguments: --uid 1000 --gid 1000 --key-file /mnt/c/Users/russe/Documents/RadioMedia-ba86f56a2aa6.json -o rw --implicit-dirs -o allow_other radiomediapodcast /mnt/c/Users/russe/Documents/gstorage
Using mount point: /mnt/c/Users/russe/Documents/gstorage
Opening GCS connection...
Opening bucket...
Mounting file system...
daemonize.Run: readFromProcess: sub-process: mountWithArgs: mountWithConn: Mount: mount: running fusermount: exit status 1
stderr:
fusermount: fuse device not found, try 'modprobe fuse' first
running gcsfuse: exit status 1
The problem you are having might be because of two things:
-Permissions on the OS after mounting, to solve this mount your bucket with the following command:
sudo mount -t gcsfuse -o implicit_dirs,allow_other,uid=1000,gid=1000,key_file=<KEY_FILE>.json <BUCKET> <PATH>
-Permissions of your service account, to validate this you can go on the console to IAM & admin and verify that the service account being used has Storage Admin Role.
We have accidently renamed shared library /lib64/libc.so.6 to be /lib64/libc.so_6. Right after previous command the system (CentOS 6.9) throws the following error :
error while loading shared libraries: /lib64/libc.so.6: cannot open shared object file: No such file or directory
When logged in within rescue mode I followed the following commands :
mount /dev/md2 /mnt
mount /dev/md1 /mnt/boot
mount -t dev -o bind /dev /mnt/dev
mount -t proc -o bind /proc /mnt/proc
mount -t sys -o bind /sys /mnt/sys
chroot /mnt
</Code>
Then i get the following error :
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
I also tried the following commands :
chroot /mnt /bin/bash
chroot /mnt/root/tmp /bin/bash
chroot /mnt/root/tmp /mnt/bin/bash
Then get another error
chroot: failed to run command ‘/mnt/bin/bash’: No such file or directory
Now the system is down and I only have ssh which failed once "libc.so.6" renamed, and rescue mode. How could I enter to system so that i can rename "libc.so_6" back to "libc.so.6"? Is there a work-around to bypass checking for "libc.so_6"?
For the sake of clarity, will post the answer here (in case someone else encounter similar trouble).
When in rescue mode:
mount /dev/md2 /mnt
mv /mnt/lib64/libc.so_6 /mnt/lib64/libc.so.6
Alternatively:
restore system from backup
try booting from some live USB (as Topper Harley proposed in comments)
Adding the following line to the /etc/fstab and rebooting seems to work as expected, i.e. al of the files in the shared directory "DEV" are available and read-only.
/etc/fstab
//192.168.99.100/DEV /mnt/dev/ cifs _netdev,username=username,password=password,ro,uid=500,gid=1001 0 0
However, I am trying to mount this the machines provisioning and avoid rebooting, so I've tried doing a "mount -a" but get the following error:
[root#localhost ~]# mount -a
mount: mount point /mnt/dev/ does not exist
How can I make this mount available without rebooting?
ok, I guess that just adding an /etc/fstab entry automatically creates the mount directory at some point during the first reboot. Soo.... in order to avoid rebooting, I apparently need to manually create the directory first
mkdir /mnt/dev
mount -a
(rejoice)
I have a small script that executes fine from my home folder but when moved to a different folder on different partition (EXT4)
$ ls -lah ./build.sh
-rwxrwxr-x 1 olmec(me) olmec(me) 510 Oct 31 20:00 ./build.sh
$ ./build.sh
bash: ./build.sh: Permission denied
I have tried chmod 777 build.sh but no difference.
The script is in folder /media/data/source
Data drive partition is mounted in FStab as
UUID=affd0ac6-f3da-4f88-ac22-65d94dc5da8c /media/data ext4 user,user 0 0
Resolved by modifying FStab mount command
UUID=affd0ac6-f3da-4f88-ac22-65d94dc5da8c media/data ext4 auto,users,exec 0 0
Most probably it's on a volume which was mounted with the noexec option, I'd check that. If that's not the case, you can still try to find out from strace bash yourscript's output.