16

I'm a chroot novice trying to make a simple chroot jail but am banging my head against the same problem time and time again... Any help would be massively appreciated

I've created a directory /usr/chroot that I want to use as a jail and created subdirectories under it and copied the dependencies of /bin/bash into it:

[root@WIG001-001 ~]# cd /usr/chroot/
[root@WIG001-001 chroot]# ls
[root@WIG001-001 chroot]# mkdir bin etc lib var home


[root@WIG001-001 chroot]# ldd /bin/bash        
linux-vdso.so.1 =>  (0x00007fff99dba000)        
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000037a2000000)        
libdl.so.2 => /lib64/libdl.so.2 (0x000000379fc00000)        
libc.so.6 => /lib64/libc.so.6 (0x000000379f800000)        
/lib64/ld-linux-x86-64.so.2 (0x000000379f400000)

[root@WIG001-001 chroot]# cp /lib64/libtinfo.so.5 /usr/chroot/lib/  
[root@WIG001-001 chroot]# cp /lib64/libdl.so.2 /udr/csr/chroot/lib/  
[root@WIG001-001 chroot]# cp /lib64/libc.so.6 /usr/chroot/lib/  
[root@WIG001-001 chroot]# cp /lib64/ld-linux-x86-64.so.2 /usr/chroot/lib/  
[root@WIG001-001 chroot]# cp /bin/bash bin  
[root@WIG001-001 chroot]# pwd  
/usr/chroot  
[root@WIG001-001 chroot]# /usr/sbin/chroot .  
/usr/sbin/chroot: cannot run command `/bin/bash': No such file or directory  


it looks like the /bin/bash created under /usr/chroot is fine as the below works:  
[root@WIG001-001 chroot]# su - nobody -s /usr/chroot/bin/bash  
-bash-4.0$

Can anyone give me any idea where to go from here?

Warner
  • 23,756
  • 2
  • 59
  • 69
Mike Atkinson
  • 191
  • 1
  • 1
  • 6
  • Is this a typo in the question or an error in the steps you performed? `cp /lib64/libdl.so.2 /udr/csr/chroot/lib/` (should be `/usr` instead of `/udr`) – Dennis Williamson Jul 20 '10 at 21:22
  • That's an artefact from using Putty to log the telnet session, sorry. As you suggest, the actual command entered was cp /lib64/libdl.so.2 /usr/chroot/lib/ – Mike Atkinson Jul 20 '10 at 21:45

4 Answers4

30

The error message is misleading: /bin/bash: No such file or directory can mean either that /bin/bash doesn't exist, or that the dynamic loader used by /bin/bash doesn't exist. (You'll also get this message for a script if the interpreter on the #! line doesn't exist.)

/bin/bash is looking for /lib64/ld-linux-x86-64.so.2 but you provided /lib/ld-linux-x86-64.so.2. Make /usr/chroot/lib64 a symbolic to lib or vice versa.

Community
  • 1
Gilles 'SO- stop being evil'
  • 9,391
  • 1
  • 33
  • 48
  • Sorry, I really appreciate the help & I'm sure you're right, but I'm still confused! I'm not sure where you see /bin/bash is being provided with /lib/ld-linux-x86-64.so.2 & I'm further confused as /usr/chroot/lib64 doesn't exist. Would it be too cheeky to ask for a list of commands? I understand sym links & how to create them, but am really confused by what's happening here and what you're suggesting to correct it. Thanks very much for your help! – Mike Atkinson Jul 20 '10 at 21:05
  • 1
    @Mike: Look at your `cp` commands: you copied files from `/lib64` in the base system into `/lib` in the chroot. But the bash binary is still looking for `ld-linux-x86-64.so.2` in `/lib64` (which you haven't created), not `/lib`. You'll save yourself headaches by making `/lib` and `/lib64` equivalent in the chroot, so run `ln -s lib /usr/chroot/lib64`. As for why the error message is about `bash` and not about `ld-linux-x86-64.so.2`, see my first paragraph. – Gilles 'SO- stop being evil' Jul 20 '10 at 22:16
  • That works perfectly, thank you so much for taking the time, it's massively appreciated! – Mike Atkinson Jul 21 '10 at 06:51
  • Great answer. In my case the problem was caused by rsync without the preserve links flag – gtsouk Oct 14 '14 at 18:03
  • Note this can also happen if you are using a different architecture via qemu and have files of the wrong architecture, or install the wrong version of qemu into the chroot. – Tully Mar 16 '16 at 06:45
  • AFAIK the output of `ldd` shows you where it ends up finding the shared library, not necessarily where it looks for it. Fx. in my case `ldd` gave me a path in `/usr/lib`, but putting the file there did not work. Instead I had to put it in `/lib`. I assume this is because on my system `/lib/` is a symlink to `/usr/lib`, and so `ldd` apparently resolves that symlink. If you experience errors I suggest putting the file in either and symlinking to the directory from the other one, say from `/lib` to `/usr/lib` or vice versa. – miyalys Mar 20 '18 at 20:28
  • 1
    @miyalys If `/lib` is a symlink to `/usr/lib` then putting a file in `/usr/lib` puts it in `/lib`, since those are the same directory! At a hunch, it didn't work at first because the loader keeps a cache of the contents of `/lib` and `/usr/lib`, and it started working when the cache was rebuilt. Running `ldconfig` rebuilds the cache, and it may have been done by you or automatically e.g. by a package manager when you installed a software update. – Gilles 'SO- stop being evil' Mar 20 '18 at 21:11
  • Thanks for the info! What I was thinking about is if one wants to create a new chroot dir for a program by copying dependencies into the new root dir, one can't rely on directly replicating the paths given by `ldd` alone, as it tells one where the shared lib is found, which is not necessarily where the program is looking for it. In the chroot dir the symlink from `/lib` to `/usr/lib` is not there unless manually created. – miyalys Mar 20 '18 at 21:40
1

Just do this: mv /usr/chroot/lib /usr/chroot/lib64

Mark Wagner
  • 18,019
  • 2
  • 32
  • 47
-1

I also faced the same error. Best way is to find the difference between rescue image (live CD) "/" content and "/mnt/sysimage" content.

Issue got resolved by coping /bin and /sbin from "/" directory to "/mnt/sysimage" where it was accidentally deleted.

#cp -r /bin /sbin /mnt/sysimage
#reboot
Jenny D
  • 27,780
  • 21
  • 75
  • 114
mayur murkya
  • 21
  • 1
-4

you shoud try copy .bashrc file in home directory. and it will help surely.

Rohit Mittal
  • 1