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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
