Dev/Embedded/Rootfs/BusyBox: Difference between revisions
(2 intermediate revisions by the same user not shown) | |||
Line 77: | Line 77: | ||
Most of the time when you start with busybox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.<br /> | Most of the time when you start with busybox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.<br /> | ||
This example targets such a very simple system : [[Dev/Embedded/Rootfs/BusyBox/Example1|Example 1 : | This example targets such a very simple system : '''[[Dev/Embedded/Rootfs/BusyBox/Example1|Example 1 : Simple system]]''' | ||
=== Example 2 : toward a complete system === | === Example 2 : toward a complete system === | ||
Line 87: | Line 87: | ||
== Create an initramfs image for the rootfs == | == Create an initramfs image for the rootfs == | ||
In order to use your base system on a diskless system you can create either an initial RAM Disk (initrd) or an initial RAM filesystem image (initramfs).<br /> | |||
Do not use an initrd ([[Dev/InitrdVSInitramfs|read here for the technical explanation]]). | |||
Creating an initramfs is pretty simple and can be done in two different ways : from the command line, on your own, or using the kernel build system.<br /> | |||
I documented both [[Dev/InitrdVSInitramfs#initramfs|at the end of the "Initrd VS Initramfs" page]] | |||
Of course, if you have access to some external storage on your target, you can use it to store your rootfs, and pass the appropriate "root=" option to the kernel from your bootloader. |
Latest revision as of 19:27, 15 January 2025
Introduction
BusyBox is "The Swiss Army Knife of Embedded Linux".
BusyBox is a "multi-call" binary which combines tiny versions of many common UNIX utilities into a single small executable.
A simple description and a full list of embeddable commands and available options can be found here.
Most information can be found in the FAQ and all around the Busybow website, but here is a short "How-To".
The information you'll find here about BusyBox will be split among three part : a common one about the basics, and two different configuration targeting two completely different kind of systems : a very simple "minimal" system, and a second more complex one.
THIS PAGE IS A WORK IN PROGRESS
Common steps
Get the sources
Either use git (below) or download a version from here : Download BusyBox sources
git clone git://git.busybox.net/busybox
You can then extract a specific version if required.
Configure
BusyBox uses a menu equivalent to the Linux kernel's one which is accessible using :
make menuconfig
There's also a "defconfig" and an "allnoconfig" target (among others), and as for the Linux kernel, the configuration is saved in a ".config" file, which can easily be shared (see bellow for example configurations for the two different example systems).
Tune to your needs and move on to the next steps :)
Some notes and warnings :
- The cross-compiling toolchain prefix can be set under "Settings"
- Note that some configuration options will greatly impact your system architecture, and some may need specific development libraries to be installed.
Compile
Still in the kernel path, cross-compilation is made using "make", with possibly more than one compilation thread.
Note that when cross-compiling you can either set the "CROSS_COMPILE=" option on the commande line or in the configuration menu.
cross_toolchain_prefix= nb_threads= make CROSS_COMPILE=${cross_toolchain_prefix} -j ${nb_threads}
An the end of the compilation the build system displays the "additionnal" required libraries (of course, the libc is always required), for example, with an almost default configuration (make defconfig) :
Final link with: m resolv
In this case, you'll need to include the libm and libresolv.
Note that there are other ways to know which libs are required in your final system exposed under the second example below.
Install BusyBox
As stated previously Busybox is a "multi-call" binary.
This means that there is a single binary called "busybox", and, in order to use other commands the usual way, one must create symlinks to this binary with the name of each command included in the busybox binary.
Hopefully, this task is automated by the BusyBox build system :).
Run :
make install
and you will get a directory called "_install" (can be changed in configuration) containing the base "bin" directories with all the links for the commands you configured.
Note that you must remove the old "_install" directory before running the new "make install".
Of course this does not make for a full system, but you already have all the binaries (or almost all depending on your needs).
Populate the base system
A Linux based system is usually not limited to a single binary. You will need some more files so you can use your system as you would use any other Linux based system.
Some of these files are mandatory, while others depend on your application and the kind of system you want to build. Usually, what you need can be split in among the following categories :
- directories
- system binaries
- libraries
- bootup script
- configuration files
- application binaries
- application related files
BusyBox installation process which installs the "busybox" binary and the symbolic links for all the selected utilities (commands), which may be most (or all) of the "system binaries".
The details for the other parts will be discussed within the examples below.
Before moving on to the next parts, let's make a short point on how to copy this "_install" directory somewhere usefull.
If you stick to a simple "cp" with no arguments, then you will get many full copies of the busybox binary instead of all the symbolic links, which is obviously not what we want.
We have three options to copy this "the right way" :
- Use "cp -a" (--archive) : The easiest way
- Use rsync (with the right set of options)
- Use tar (make an archive with "tar -c", and then extract somewhere else with "tar -x").
I'm using the "cp -a" solution most of the time, unless I want to keep a backup somewhere (and use the tar solution).
Let's now move to the next steps required to build a the base system with two examples.
Example 1 : simple system
Most of the time when you start with busybox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.
This example targets such a very simple system : Example 1 : Simple system
Example 2 : toward a complete system
If you want to use BusyBox as the heart of an almost complete but light system, with multi-user, many services (possibly including SSH for remote access) you will need some more stuff than the pretty small configuration from the previous example.
I started collecting some more information to build a more complex Linux based system using BusyBox as a base for the userland part of the system, but it is very incomplete, currently only a collection of the bits which were going too far for the first "simple example".
Example 2 : toward a complete system ( TO BE COMPLETED )
Create an initramfs image for the rootfs
In order to use your base system on a diskless system you can create either an initial RAM Disk (initrd) or an initial RAM filesystem image (initramfs).
Do not use an initrd (read here for the technical explanation).
Creating an initramfs is pretty simple and can be done in two different ways : from the command line, on your own, or using the kernel build system.
I documented both at the end of the "Initrd VS Initramfs" page
Of course, if you have access to some external storage on your target, you can use it to store your rootfs, and pass the appropriate "root=" option to the kernel from your bootloader.