Service Manual busybox manual download for free

Published on May 2017 | Categories: Documents | Downloads: 64 | Comments: 0 | Views: 368
of 6
Download PDF   Embed   Report

Comments

Content

Link to Downl0ad busybox manual

Downl0ad busybox manual

Pdf guide busybox manual download free version

BusyBox simplifies embedded Linux systems
The birth of BusyBox
BusyBox was first written by Bruce Perens in 1996 for the Debian GNU/Linux setup disk. The goal was to create a bootable
GNU/Linux system on a single floppy disk that could be used as an install and rescue disk. A single floppy disk can hold
around 1.4-1.7MB, so there's not much room available for the Linux kernel and associated user applications.

BusyBox license
BusyBox is licensed under the GNU General Public License (GPL). This means that if you use BusyBox in a project, you
must abide by the license. You can view the license on the BusyBox Web site (see the Resources section later in this
article). The BusyBox team appears to keep busy by monitoring violators of their license. In fact, they maintain a "Hall of
Shame" page to document violations.
BusyBox exploits the fact that the standard Linux utilities share many common elements. For example, many file-based
utilities (such as grep and find ) require code to recurse a directory in search of files. When the utilities are combined into a

single executable, they can share these common elements, which results in a smaller executable. In fact, BusyBox can
pack almost 3.5MB of utilities into around 200KB. This provides greater functionality to bootable floppy disks and
embedded devices that use Linux. You can use BusyBox with both the 2.4 and 2.6 Linux kernels.

How does BusyBox work?
To make one executable look like many executables, BusyBox exploits a seldom-used feature of argument passing to the
main C function. Recall that the C main function is defined as follows:

POSIX environment
While BusyBox aims to provide a relatively complete Portable Operating System Interface (POSIX) environment, that's a
desire and not a requirement. The utilities aren't complete, but they do provide the major functionality expected of them.
Listing 1. The C main function

In this definition, argc is the number of arguments passed in (argument count) and argv is an array of strings representing
options passed in from the command line (argument vector). Index 0 of argv is the program name that was invoked from
the command line.
The simple C program shown in Listing 2 demonstrates BusyBox invocation. It simply emits the contents of the argv
vector.
Listing 2. BusyBox uses argv[0] to determine which application to invoke

Invoking this application shows that the first argument invoked is the name of the program. You can rename your
executable, and you get the new name upon invocation. Further, you can create a symbolic link to your executable, and
you get the symlink name when it's invoked.
Listing 3. Command testing after updating BusyBox with a new command

BusyBox uses symbolic links to make one executable look like many. For each of the utilities contained within BusyBox, a
symbolic link is created so that BusyBox is invoked. BusyBox then invokes the internal utility as defined by argv[0] .

Configuring and building BusyBox
You can the latest version of BusyBox from its Web site (see the Resources section). Like most open source programs, it's
distributed in a compressed tarball, and you can transform it into a source tree using the command in Listing 4. (If you ed a
version other than 1.1.1, use the appropriate version number in this and other version-specific commands.)
Listing 4. Untarring BusyBox

The result is a directory, called busybox-1.1.1, that contains the BusyBox source code. To build the default configuration,
which includes almost everything with debugging disabled, use the defconfig make target:

BusyBox source tree
The source tree for BusyBox is well organized. Utilities are categorized based on their use and stored in separate
subdirectories. For example, the networking utilities and daemons (such as httpd. ifconfig. and so on) are in the
./networking directory; standard module utilities (including insmod. rmmod and lsmod ) are in the ./modutils directory; and
editors (such as vi. and stream editors such as awk and sed ) are in the ./editors directory. The makefiles and various
documents for configuring, building, and installing are at the root of the tree.
Listing 5. Building the default BusyBox configuration

The result is a rather large BusyBox image, but it's the simplest way to get started. You can invoke this new image directly,
which results in a simple Help page with the currently configured commands. To test your image, you can also invoke
BusyBox with a command to execute, as shown in Listing 6.
Listing 6. Demonstrating BusyBox command execution and the ash shell in BusyBox

In this example, you invoke the pwd (print working directory) command, enter the ash shell within BusyBox, and invoke
pwd within ash .

Manual configuration
If you're building an embedded device that has very specific needs, you can manually configure the contents of your
BusyBox with the menuconfig make target. If you're familiar with building a Linux kernel, note that menuconfig is the same
target for configuring the contents of the Linux kernel. In fact, the ncurses-based application is the same.

Using manual configuration, you can specify the commands to be included in the final BusyBox image. You can also
configure the BusyBox environment, such as including support for the United States National Security Agency's (NSA)
Security-Enhanced Linux (SELinux), specifying the compiler to use (for cross-compiling in an embedded environment), and
whether BusyBox should be compiled statically or dynamically. Figure 1 shows the main screen for menuconfig. Here you
can see the different major classes of applications (applets) that you can configure for BusyBox.
Figure 1. BusyBox configuration using menuconfig

Multiple architecture support
Being able to easily specify the cross-compiler for BusyBox means that you can build BusyBox for a wide variety of
architectures. To build BusyBox for your target architecture, you need a cross-compiler and a version of the C library
(uClibc or glibc) that has been compiled for the particular target architecture.
To manually configure BusyBox, use the following commands:
Listing 7. Manually configuring BusyBox

This provides you with a BusyBox binary that can be invoked. The next step is to build an environment around BusyBox,
including the symbolic links that redirect the standard Linux commands to the BusyBox binary. You can do this very simply
with the following command:
Listing 8. Building the BusyBox environment

By default, a new local subdirectory is created, called _install, which contains the basic Linux environment. At the root,
you'll find a linuxrc program that links to BusyBox. The linuxrc program is useful when building an install or rescue disk
(permits a modularized boot prior). Also at the root is a /sbin subdirectory that contains operating system binaries (used
primarily for administration), and a /bin subdirectory that contains binaries intended for users. You can then migrate this
_install directory into your target environment when building a floppy distribution or embedded initial RAM disk. You can also
use the PREFIX option with the make program to redirect the install subdirectory to a new location. For example, the
following code segment installs the symlinks using the /tmp/newtarget root directory instead of the ./_install directory:
Listing 9. Installing symlinks to another directory

The links that are created through the install make target come from the busybox.links file. This file is created when
BusyBox is compiled, and it contains the list of commands that have been configured. When install is performed, the
busybox.links file is checked for the symlinks to create.
The command links to BusyBox can also be created dynamically at runtime using BusyBox. The
CONFIG_FEATURE_INSTALLER option enables this feature, which can be performed at runtime as follows:
Listing 10. Creating command links at runtime

The -s option forces symbolic links to be created (otherwise, hard links are created). This option requires that the /proc file
system is present.

BusyBox build options
BusyBox includes several build options to help you build and debug the right BusyBox for you.
Table 1. Some of the make options available for BusyBox

The Software Freedom Conservancy acts as the GPL enforcement agent for various BusyBox copyright holders. If you
wish to report a GPL violation on BusyBox, please write to [email protected].
I want to thank the following companies which are providing support for the BusyBox project:
Analog Devices, Inc. provided a Blackfin development board free of charge. Blackfin is a NOMMU processor, and its availability
for testing is invaluable. If you are an embedded device developer, please note that Analog Devices has an entire Linux
distribution available for for this board. Visit http://blackfin.uclinux.org/ for more information.
AOE - Open Source Web Development contributes financially.

25 March 2016 -- Building on an Android tablet.
Android is based on Linux kernel, but sadly and unexplicably, Android userspace is not Unix-friendly: in many cases, things
are done differently than in "usual" Unix systems. For example, there is no /bin directory (and therefore ubiquitous
#!/bin/sh scripts won't work). Instead, there is /system/bin.
I have a Samsung Galaxy Tab S (SM-T700 model) and I made it compile Busybox as follows:
"Rooted" the tablet (acquired root access). This step is device-specific.
Installed SuperSU application.
Installed the Termux application - it provides a small repository of essential tools: gcc-based toolchain, git, ncurses, etc.

Ran its terminal, installed packages I needed, pulled Busybox git tree.
Created a /bin symlink to /system/bin, to make #!/bin/sh scripts work (the build fails otherwise).
Now the usual "make defconfig", "make menuconfig", "make" work.
Some parts won't compile (not all kernel headers are present, libc API different or incomplete, etc). The maximal config
which did compile is now in the git tree, in configs/android_502_defconfig. The toolchain provided by Termux is based on
Android's Bionic libc and Bionic has some design problems. An annoying one is that off_t is 32-bit, struct_stat::st_size is
not off_t (this voilates standard expectations), therefore CONFIG_LFS=y does not build, and CONFIG_LFS=n builds with
warnings (printf'ing st->st_size with wrong specifier).

24 March 2016 -- BusyBox 1.24.2 (stable)
Bug fix release. 1.24.2 has fixes for build system (static build with glibc fixed), truncate, gunzin and unzip.

24 October 2015 -- BusyBox 1.24.1 (stable)
Bug fix release. 1.24.1 has fixes for ftpd (DIR parameter works for non-root too), httpd (heap overflow fix), sort (fix for a
a problem affecting glibc build). Build system has a fix for the lost link-time optimizations. In 1.24.0 announcement, you
might have noticed that sizes unexpectedly grew relative to 1.23.2. Now it is fixed:
Check out a new applet, "uevent". It is a netlink listener. It provides alternative to having mdev as kernel hotplug helper.
Instead of setting up the former via "echo /sbin/mdev >/proc/sys/kernel/hotplug", start "uevent mdev" early during boot.
"uevent" will run "mdev" for each hotplug event, waiting for each child to terminate before starting a next one.
The former method does not require a long-lived listener process, but it is racy: many copies of mdev can run in parallel.

12 October 2015 -- BusyBox 1.24.0 (unstable)
Sizes of busybox-1.23.2 and busybox-1.24.0 (with equivalent config, static uclibc build):
I would like to feature some less-known useful tools in Busybox. Let me talk about "nmeter" applet. I find myself using it
surprisingly often. For example, it helped me to correctly parallelize a very large multiple kernel build job (
30000 kernel builds) so that all CPUs are loaded, but machine isn't evicting file cache because it has too many jobs for
installed RAM.
When dealing with a machine which seems to be sluggish, it takes some time to pinpoint the cause. It can be lack of free
memory. It can be excessive CPU load. It can be misbehaving (slow) storage or network. nmeter allows to monitor many
such parameters and presents them in a compact one-line form. This lets you see the time evolution as well. Here is an
example:
If CPU load is high, the CPU bar will immediately show this. %x column shows context switches per second, allowing to
detect cases where processes are waking and waiting on each other excessively. %[mf] is free memory, and it is smart
enough to show actual usable memory: unlike many other tools, it considers buffer cache as free memory. %p and %[pn]
columns show forks and number of processes, they let you detect a case where a daemon is respawning continuously.
Two %b numbers are block IO read and write rates. %[neth0] is network IO rate on the specified interface. More specifiers
exist - please read "nmeter --help" output.
With -d MSEC option and small values of MSEC, this tool allows to see a detailed view of bursty activity. Sometimes you
can literally see every network packet arriving. To make this possible, this tool is written so that it reads the minimum of
informaion it needs from /proc. In this example, we can see how a packet arrived to eth0, complete with its IRQ#30 firing:
As you see, each update takes about 0.2 millisecond of processing time. You can run even -d1, if you want. -d0 also
works, it is a mode where updates are continuous.
On the other hand, with large update interval, you can run this tool continuously on a server machine and save its output,
to be able to investigate mysterious drops in performance at a time when there was no operator present. If you have an
oopsing server, it is useful to have another nmeter instance's output to be constantly printed to its console, if you want to
see what was going on just before oops. "Is my server occasionally dies in an IRQ storm?" situation.
Changes since previous release:

23 March 2015 -- BusyBox 1.23.2 (stable)
Bug fix release. 1.23.2 has fixes for dc (more tolerant to lack of whitespace), modinfo (was not ignoring directory
component of path names in a few places), modprobe (better compatibility for "rmmod" alias), wget (--header now
overrides built-in headers, not appends to).

23 March 2015 -- BusyBox 1.23.2 (stable)
Bug fix release. 1.23.2 has fixes for dc (more tolerant to lack of whitespace), modinfo (was not ignoring directory
component of path names in a few places), modprobe (better compatibility for "rmmod" alias), wget (--header now
overrides built-in headers, not appends to).

27 January 2015 -- BusyBox 1.23.1 (stable)
Bug fix release. 1.23.1 has fixes for ash (fixed a problem with $<#N> expansion), ftpd (fixed "zombie apocalypse"),
modprobe (was not ignoring directory component of path names in a few places), vi.

23 December 2014 -- BusyBox 1.23.0 (unstable)

Sizes of busybox-1.22.1 and busybox-1.23.0 (with equivalent config, static uclibc build):
Changes since previous release:

20 January 2014 -- BusyBox 1.22.1 (stable)
Bug fix release. 1.22.1 has fixes for find (was requiring the path argument in some cases, unlike GNU find), grep (fixes for w handling), ntpd (wasn't slewing time after large negative step), compile fixes for some configurations.

1 January 2014 -- BusyBox 1.22.0 (unstable)
Sizes of busybox-1.21.1 and busybox-1.22.0 (with equivalent config, static uclibc build):
Changes since previous release:

29 June 2013 -- BusyBox 1.21.1 (stable)
Bug fix release. 1.21.1 has fixes for ntfs detection (big-endian fix), xz decompression of concatenated streams, mdev
acquired a [ENV=regex;] extension instead of undocumented subsystem match hack it used to have prior to 1.21.x.

21 January 2013 -- BusyBox 1.21.0 (unstable)
Sizes of busybox-1.20.2 and busybox-1.21.0 (with equivalent config, static uclibc build):
Changes since previous release:

2 July 2012 -- BusyBox 1.20.2 (stable)
Bug fix release. 1.20.2 has fixes for ash (fix for variable expansion in redirection), ifup/down (fix for "pre-up" and "predown" handling), man (fixes for compressed man pages handling), mke2fs (important fix! due to misplaced s_mkfs_time
field, ext4 driver couldn't mount our images), ps (fix for getting uptime on non-Linux platforms), tar (fix base-256
decoding).

Busybox Guide
Busybox?
BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for
most of the utilities you usually find in GNU fileutils, shellutils, etc. For more information you can visit busybox homepage .

Why Trickster MOD requires Busybox?
All root apps rely on shell (command line) commands to do their dirty work, Trickster MOD is not an exception. In addition
to standard commands that are likely provided by the manufacturer of your device, Trickster MOD also needs a lot more
commands as internally the app relies on a shell (commandline) script to generate its GUI dynamically, get and set setting
values. These commands are provided by busybox.

Why my device failed busybox test in Trickster MOD
Unlike other apps who simply use busybox command without checking, to make sure that things work like how they are
supposed to, Trickster MOD check the following busybox requirements:
busybox must be present under a directory listed in device $PATH environment variable, e.g. under /system/xbin or
/system/bin
busybox binary version equals or higher than 1.20: older version has bug in find applet
busybox binary must have the following applets: awk, base64, cat, chmod, chown, cp, cut, dd, dirname, echo, egrep, expr,
fgrep, find, fold, grep, gunzip, gzip, head, id, insmod, kill, killall, killall5, ln, lsmod, mkswap, mount, mv, pgrep, pkill, printf,
ps, rm, rmdir, rmmod, sed, seq, sleep, sort, swapoff, swapon, sysctl, tail, tar, touch, tr, umount, uname, uniq, wc, which,
xargs, zcat
Above applets must be correctly symlinked
If your device fails busybox test, it must have failed one of the criteria above, e.g.:
No busybox installed or have one but older than 1.20
Missing required symlinked applet(s)
0 byte busybox due to force restart right after busybox installation

Why does Trickster MOD work before and not now?

Because the app uses an internal busybox before. Now with the introduction of KNOX Samsung devices and some
SELinux enabled devices. We can’t run internal binary as root on some configuration so we have to remove it.

How can I fix it?
If you haven’t done so, please use this app or it directly here . After installing it, please open the app and install
busybox into your device.
In case, you still have busybox problem after using this busybox installer, please send us a report like asked in the Trickster
MOD.
BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides minimalist
replacements for most of the utilities you usually find in GNU coreutils, util-linux, etc. The utilities in BusyBox generally have
fewer options than their full-featured GNU cousins; however, the options that are included provide the expected
functionality and behave very much like their GNU counterparts.
BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can
easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded
systems. To create a working system, just add /dev, /etc, and a Linux kernel. BusyBox provides a fairly complete POSIX
environment for any small or embedded system.
BusyBox is extremely configurable. This allows you to include only the components you need, thereby reducing binary size.
Run 'make config' or 'make menuconfig' to select the functionality that you wish to enable. Then run 'make' to compile
BusyBox using your configuration.
After the compile has finished, you should use 'make install' to install BusyBox. This will install the 'bin/busybox' binary, in
the target directory specified by CONFIG_PREFIX. CONFIG_PREFIX can be set when configuring BusyBox, or you can
specify an alternative location at install time (i.e. with a command line like 'make CONFIG_PREFIX=/tmp/foo install'). If you
enabled any applet installation scheme (either as symlinks or hardlinks), these will also be installed in the location pointed to
by CONFIG_PREFIX.
BusyBox is a multi-call binary. A multi-call binary is an executable program that performs the same job as more than one
utility program. That means there is just a single BusyBox binary, but that single binary acts like a large number of utilities.
This allows BusyBox to be smaller since all the built-in utility programs (we call them applets) can share code for many
common operations.
You can also invoke BusyBox by issuing a command as an argument on the command line. For example, entering
will also cause BusyBox to behave as 'ls'.
Of course, adding '/bin/busybox' into every command would be painful. So most people will invoke BusyBox using links to
the BusyBox binary.
For example, entering
will cause BusyBox to behave as 'ls' (if the 'ls' command has been compiled into BusyBox). Generally speaking, you should
never need to make all these links yourself, as the BusyBox build system will do this for you when you run the 'make
install' command.
If you invoke BusyBox with no arguments, it will provide you with a list of the applets that have been compiled into your
BusyBox binary.
Most BusyBox applets support the --help argument to provide a terse runtime description of their behavior. If the
CONFIG_FEATURE_VERBOSE_USAGE option has been enabled, more detailed usage information will also be available.
Currently available applets include:
acpid [-d] [-c CONFDIR] [-l LOGFILE] [-e PROC_EVENT_FILE] [EVDEV_EVENT_FILE. ]
Listen to ACPI events and spawn specific helpers on event arrival
Accept and ignore compatibility options -g -m -s -S -v
addgroup [-g GID] [user_name] group_name
Add a group or add a user to a group
adduser [OPTIONS] user_name
adjtimex [-q] [-o offset] [-f frequency] [-p timeconstant] [-t tick]
Read and optionally set system timebase parameters. See adjtimex(2) .
ar [-o] [-v] [-p] [-t] [-x] ARCHIVE FILES
Extract or list FILES from an ar archive

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close