Search $PATH failure?

[Bart Kus]

Thanks for the tip on /proc/self/exe.  Setting 
CONFIG_FEATURE_PREFER_APPLETS=n remedied the $PATH problem!

Thanks!

--Bart


On 12/1/2011 9:47 PM, Harald Becker wrote:
>   Hallo Bart!
>
> On 02.12.2011 05:45, Bart Kus wrote:
>> On 12/1/2011 6:37 PM, Harald Becker wrote:
>>> IMHO as your question contains massive novice failures I suggest
>>> reading a book or other sources of information about Unix/Posix sytem
>>> basics (before asking in a specialized mailing list like Busybox). --
>>> Harald
>> Ok, let's try this again, this time when a bit less sleep deprived:
>>
>>
>> jo tmp # (mkdir ram&&  cd ram&&  gunzip<  /boot/initramfs | cpio -idm)
>> 37624 blocks
>> jo tmp # PATH= /usr/bin/chroot ram bin/busybox ash
>> / # PATH=/bin:/usr/bin
>> / # export PATH
>> / # echo $PATH
>> /bin:/usr/bin
>> / # uname
>> ash: uname: not found
> Ohps! ...<thinking>
>
>> / # ls -l /bin/uname /bin/busybox
>> -rwxr-xr-x    1 0        0          2087264 Dec  1 09:03 /bin/busybox
>> lrwxrwxrwx    1 0        0                7 Dec  2 04:14 /bin/uname ->
>> busybox
>> / #
>>
>>
>> I don't think the device node failures have anything to do with $PATH
>> processing, but they've been addressed in this example.
> I don't know the exact reasons for the device node failures ... did you
> do this as root user now or as a different user? ... if now at root user
> it was probably due to missing permissions to create the device nodes.
>
>> It's sufficient to just set PATH=/bin without exporting since I don't
>> care if the uname process environment has a PATH variable.  In this
>> example $PATH is only set so ash can use it to find uname and execute
>> it.  However I've exported it as per your request.
> You are right for plain uname util, but there is a difference in Busybox
> implementation. Busybox is a single binary sharing several commands. To
> minimize size of that common binary it uses common Busybox library
> routines and (sometimes) calls code of other commands internally. For
> this and for several C library calls a proper environment setting (PATH
> and some other variables) is required. Due to this you need to export
> PATH from the shell to the invoked command.
>
> In addition this export is required only once in a shell process. As
> soon as a variable is marked for export it is sufficient to change its
> value "PATH=". The export status is remembered and the variable content
> is exported to every command invoked afterwards.
>
>> Now, to flex the code path where $PATH is set to a sufficient value
>> prior to busybox/ash execution, here's the last example:
>>
>> jo tmp # PATH=/bin:/usr/bin /usr/bin/chroot ram bin/busybox ash
>> / # echo $PATH
>> /bin:/usr/bin
>> / # uname
>> ash: uname: not found
>> / #
>>
>> You agree this is incorrect behavior, yes?
> Ohps! ...<thinking again>  ... ahhh ... is your Busybox compiled with
> that standalone feature? ... which path to the executeable binary is
> compiled into your Busybox (probably /proc/self/exe, the default). So
> you are in big trouble in a chroot environment if there is no mounted
> proc directory!
>
> Try this at first:
>
> PATH=/bin:/usr/bin /usr/bin/chroot ram bin/busybox ash
> echo $PATH
> /bin/uname
>
> If that works (I suppose it will), Your Busybox ash is looking for it's
> compiled in executeable.
>
> Try this:
>
> mkdir /tmp/ram/proc
> mount -t proc proc /tmp/ram/proc
> PATH=/bin:/usr/bin /usr/bin/chroot ram bin/busybox ash
> echo $PATH
> uname
>
> ... and now?
>
>
>> PS: It looks like if I substitute the busybox that emerge generates
>> vs. the one that genkernel creates this problem no longer manifests.
> Yep that is true! The Gentoo emerge system changes some of the default
> Busybox configurations. One of the values it changes is the executeable
> path ... one reason why I do not use the Busybox from the automatic
> build process.
>
>
>> I'll need a bit more time to figure out where genkernel might be going
>> wrong.
> It doesn't seem that genkernel goes wrong, it is just different. The
> Busybox created by genkernel probably uses slightly different
> configuration options for the Busybox build. This results in different
> requirements in your final installation.
>
> I hope that fixes your trouble.
>
> --
> Harald