Joshua Ball wrote: > chroot: cannot run command `/bin/bash': No such file or directory
The no such file almost certainly refers to missing required shared libraries causing the exec(2) system call to fail. > I get similar error messages when trying to run false, ls, pwd, > scponly, and true instead of bash. However, if I try to run sash, > everything works perfectly. > > # chroot /chroot /bin/sash > Stand-alone shell (version 3.7) sash is a statically linked binary and does not use any shared libraries. That is why sash is successful but bash is not. bash is dynamically linked and requires the linked shared libs to be present. > My suspicion is that chroot can't start bash or the other programs > because they rely on linux-gate.so.1 (according to ldd), and that > library is not in my chrooted environment. All of the shared libraries are required. See any of the many chroot howtos that are available on how to set up a chroot environment. I recommend starting here: http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot If you install all of the required shared libraries then bash will work fine too. > However, that's beyond the scope of this bug. Actually it is exactly the opposite. That is the core of your issue. You must have all of the shared libraries installed in your chroot in order to successfully run commands that use those shared libraries. Doing so is outside the scope of the chroot system call. The chroot utility is simply a command line interface to the chroot system call. It is not the chroot call that is failing. It would be the execvp() call that is failing and returning ENOENT. The exec(2) system call is in the kernel. But actually I don't think there is much that can be done about your particular issue. The failure is too indirect. > I'm reporting this bug because the error message that chroot yields, > namely "no such file or directory" is wrong. Instead it should say > something to the effect of "Missing shared library > /lib/ld-linux.so.2", depending on the actual problem. In this case the coreutils chroot utility is simply the middle man. It is a command line interface to the chroot system call. The system call has returned an error message and the utility is reporting the error. It is passing the error ENOENT that is returned from execvp(2) back to the caller. > Am I right to report the bug here, or should I just go upstream? A lot > of people on the internet have the same problem as me that aren't > using Debian. I really don't think there is much that can be done about this issue. The exec(2) kernel call is failing and the reason it reported is ENOENT. In order to do something different it would need a different error message. But the errors that are allowed to be produced are standardized. http://www.opengroup.org/onlinepubs/009695399/functions/exec.html Of the list ENOENT is the most appropriate error. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
