Dev/Embedded/Rootfs/BusyBox/Example1
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 explains how to create a minimal Linux based base system using BusyBox as a base for the userland part of the system.
Minimal configuration
You can start with this example minimal config.
Some information about my choices :
- This configuration is based upon the "defaultconfig", but with many modifications (not all listed here)
- No "/usr" support (all binaries under /bin and /sbin)
- Archival utilities limited to tar with "xz" and "bz2" support
- Removed console utilities
- Removed most users handling utilities : users should be known when building the system (or added by direct editting of the files)
- Removed disk partitionning and formatting utilities save for UBIFS
- Removed runit support
- Removed all commands I never used on a full blown system
Compile using uClibc
The options selected for a minimal configuration should not impact the compilation process, unless you want a really small system, which is common when using BusyBox due to storage size constraints.
In this case using uClibc instead of the GNU libc is a good idea.
Most information about using uClibc in a cross-compilation toolchain can be found on uClibc website.
You will then need to use the cross-compilation prefix of your toolchain to build BusyBox.
With a stripped down BusyBox, you may well end up with :
Final link with: <none>
But note that in this case you'll still need the selected libc (uClibc) !
Directories and links
Here is a very simple set of directories for a configuration without "/usr", according to the minimal configuration given above :
mkdir -p dev etc lib/{modules,firmware} proc root run sys var/{log,spool/cron}
Then add some links :
ln -s run/tmp tmp ln -s ../run/tmp var/tmp
Libraries
As this is a very simple system the set of libraries should be very limited. You may need additional ones for your application binaries so I cannot give you a full list, but if you chose to have dynamically linked binaries (which is usually a good idea if your system has more than one or two binaries) you will always need these two :
- The dynamic linker/loader (name depending on the target architecture/triplet) : ld-linux-*.so.*
- the libc
In order to check for additional library requirements, have a look at this part in the second example below.
Once you know which libraries you need, you'll need to figure which files to put in which directory for each library.
Unless you specified an absolute or relative pathname during the linking stage of the compilation of your binaries, there is no "fixed" location for each library file, save maybe the dynamic linker/loader (ld-linux-*.so.*), which usually goes under "/lib", and the dynamic linker will end up looking for libraries in some "default" path which usually includes "/lib".
So the easy way is to create a single "/lib" directory (remember that we chose to desactivate the use of "/usr" in BusyBox configuration).
Bootup script(s)
Now Busybox seems to support two init systems : the historic one sharing similarities to SysVinit (without the runlevels) and one similar to runnit.
I choose to disable runnit support in this minimal configuration, so the "init" applet will look for the "/etc/inittab" configuration file.
There is an example one under "examples/" in BusyBox source tree.
Anyway, even without this file the applet will look for a script called "/etc/init.d/rcS" and, even if it found none, start an "askfirst" shell (display the message "Please press Enter to activate this console." which would then give you a prompt).
So here is a short list of files for the init part of the base system :
- /etc/inittab
- /etc/init.d/rcS and rc script(s)
Configuration files
TO BE COMPLETED
- /etc/nologin
- /etc/securetty
- /etc/shells
- /etc/{passwd,shadow,groups}
Application binaries
TO BE COMPLETED
TO BE COMPLETED