On 17-08-31 14:43:10, Rick Stevens wrote:
On 08/31/2017 11:14 AM, Tony Nelson wrote:
On 17-08-31 12:41:09, Mike Wright wrote:
How about using "env": env PATH="new_path" chroot /some_dir
Wouldn't this preempt the passed PATH, profile, bashrc, and the dot files? If so, chroot could be defined as an alias to "env ...
chroot"
and thereby eliminate the problem.
Seems to work. Note that this only changes the passed path; any pathmunge()'ing in the chroot's startup scripts still happens. I've already fixed the problem inside the chroot, but I'll set this up if I find another problematic chroot. It should be OK to look at /usr/bin twice if /bin -> /usr/bin and the command doesn't exist.
If the pathmunging is done in a "/<wherever-chroot-is>/etc/..." script or in a "~/.whatever", absolutely as that is done after the chroot spawns the shell in the chrooted environment. If you're saying it happens before the chroot, then I don't know how that'd occur.
No, I didn't say that. I said "I've already fixed the problem inside the chroot".
I think the issue you've been having is that your chroot environment doesn't have the merged /bin and /usr/bin. It has separate /bin and /usr/bin directories. After the merge of /bin and /usr/bin was established, I believe bash's built-in default PATH was modified to assume this symlink was done. That's why the new bash doesn't have a separate "/bin" in its default path.
bash's default path is not being used; if it were, it would be the CentOS5 bash. PATH is set in the chroot environment by chroot itself, which is how the outer PATH or the env PATH get into it. The f20 chroot works because it postdates the /bin -> /usr/bin merge and doesn't need /bin in PATH. CentOS5 has separate /bin and /usr/bin, and needs /bin in PATH. That can be passed in, as with env, or done in the chroot by pathmunge'ing in a bash startup script in /etc/profile.d (both /etc/profile and /etc/bashrc source that directory).