From 380ad123ac5586ce321b171536a939e296d8b71d Mon Sep 17 00:00:00 2001
From: Rob Landley
+ If you just want to try out busybox without installing it, download the
+ tarball, extract it, run "make allyesconfig", and then run "make".
+
+ This will create a busybox binary with all features enabled. To try
+ out a busybox applet, type "./busybox [appletname] [options]", for
+ example "./busybox ls -l" or "./busybox cat LICENSE". Type "./busybox"
+ to see a command list, and "busybox appletname --help" to see a brief
+ usage message for a given applet.
+
+ BusyBox uses the name it was invoked under to determine which applet is
+ being invoked. (Try "mv busybox ls" and then "./ls -l".) Installing
+ busybox consists of creating symlinks (or hardlinks) to the busybox
+ binary for each applet in busybox, and making sure these symlinks are in
+ the shell's command $PATH. ("make install" creates these symlinks, and
+ "make install-hardlinks" creates hardlinks instead.) The special applet
+ name "busybox" (or with any optional suffix, such as "busybox-static")
+ uses the first argument to determine which applet to run, as shown above.
+
+ BusyBox also has a feature called the "standalone shell", where the busybox
+ shell runs any built-in applets before checking the command path. This
+ feature is also enabled by "make allyesconfig", and to try it out run
+ the command line "PATH= ./busybox ash". This will blank your command path
+ and run busybox as your command shell, so the only commands it can find
+ (without an explicit path such as /bin/ls) are the built-in busybox ones.
+ This is another good way to see what's built into busybox. (Note that the
+ standalone shell is dependent on the existence of /proc/self/exe, so before
+ using it in a chroot environment you must mount /proc.)
+
+ To build a smaller busybox binary, run "make menuconfig" and disable the
+ features you don't need. (Or run "make allnoconfig" and then use
+ menuconfig to add just the features you need. Don't forget to recompile
+ with "make" once you've finished configuring.)
+
+ BusyBox is a package that replaces a dozen standard packages, but it is
+ not by itself a complete bootable system. Building an entire Linux
+ distribution from source is a bit beyond the scope of this FAQ, but it
+ understandably keeps cropping up on the mailing list, so here are some
+ pointers.
+
+ Start by learning how to strip a working system down to the bare essentials
+ needed to run one or two commands, so you know what it is you actually
+ need. An excellent practical place to do
+ this is the Linux
+ BootDisk Howto, or for a more theoretical approach try
+ From
+ PowerUp to Bash Prompt.
+
+ To learn how to build a working Linux system entirely from source code,
+ the place to go is the Linux
+ From Scratch project. They have an entire book of step-by-step
+ instructions you can
+ read online
+ or
+ download.
+ Be sure to check out the other sections of their main page, including
+ Beyond Linux From Scratch, Hardened Linux From Scratch, their Hints
+ directory, and their LiveCD project. (They also have mailing lists which
+ are better sources of answers to Linux-system building questions than
+ the busybox list.)
+
+ If you want an automated yet customizable system builder which produces
+ a BusyBox and uClibc based system, try
+ buildroot, which is
+ another project by the maintainer of the uClibc and BusyBox projects
+ (Erik Andersen). Download the tarball, extract it, unset CC, make.
+ For more instructions, see the website.
+
-
-
- Full functionality requires Linux 2.2.x or better. A large fraction of the
+ Full functionality requires Linux 2.4.x or better. (Earlier versions may
+ still work, but are no longer regularly tested.) A large fraction of the
code should run on just about anything. While the current code is fairly
Linux specific, it should be fairly easy to port the majority of the code
to support, say, FreeBSD or Solaris, or Mac OS X, or even Windows (if you
are into that sort of thing).
-
-
+
-
-
BusyBox in general will build on any architecture supported by gcc.
- Kernel module loading for 2.2 and 2.4 Linux kernels is currently
+ Kernel module loading for 2.4 Linux kernels is currently
limited to ARM, CRIS, H8/300, x86, ia64, x86_64, m68k, MIPS, PowerPC,
S390, SH3/4/5, Sparc, v850e, and x86_64 for 2.4.x kernels.
-
+
With 2.6.x kernels, module loading support should work on all architectures.
-
-
+
-
-
- uClibc and glibc are supported. People have been looking at newlib and
- dietlibc, but they are currently considered unsupported, untested, or
- worse. Linux-libc5 is no longer supported. If you require a small C
- library, you should probably use uClibc.
-
-
+ On Linux, BusyBox releases are tested against uClibc (0.9.27 or later) and
+ glibc (2.2 or later). Both should provide full functionality with busybox,
+ and if you find a bug we want to hear about it.
+
+
+
+How can I get started using BusyBox?
+
+
+How do I build a BusyBox-based system?
+
Which Linux kernel versions are supported?
Which architectures does BusyBox run on?
Which C libraries are supported?
+ Some BusyBox applets have been built and run under a combination + of newlib and libgloss (see + this thread). + This is still experimental, but may be supported in a future release. +
-
- - An easy method to build your own basic BusyBox based system, is to - follow these simple steps: -