Busy Box init

Among the commands it supports by default, BusyBox provides init-like capabilities. As with the original mainstream init, BusyBox can handle the system's startup. BusyBox init is particularly well adapted to embedded systems, because it provides most of the init functionality an embedded system typically needs without dragging the weight of the extra features found in System V init. Also, because BusyBox is a single package, there is no need to keep track of an additional software package when developing or maintaining your system. There are cases, however, where BusyBox init may not be sufficient for your system. BusyBox init, for example, does not provide runlevel support.

Since I already described how to obtain, configure, and build BusyBox, I will limit this discussion to the setup of the init configuration files.

Because /sbin/init is a symbolic link to /bin/busybox, BusyBox is the first application to run on the target system. BusyBox identifies that the command being invoked is init and immediately jumps to the init routine.

The init routine of BusyBox carries out the following main tasks in order:

1. Sets up signal handlers for init.

2. Initializes the console(s).

3. Parses the inittab file, /etc/inittab.

4. Runs the system initialization script. /etc/init.d/rcS is the default for BusyBox.

5. Runs all the inittab commands that block (action type: wait).

6. Runs all the inittab commands that run only once (action type: once).

Once it has done this, the init routine loops forever carrying out the following tasks:

1. Runs all the inittab commands that have to be respawned (action type: respawn).

2. Runs all the inittab commands that have to be asked for first (action type: askfirst).

During console initialization, BusyBox determines whether the system was configured to run the console on a serial port (by passing console=ttyso as a kernel boot parameter, for instance). If so, BusyBox versions prior to 0.60.4 used to disable all virtual terminals. Since 0.60.4, however, BusyBox continues through its initialization without disabling virtual terminals. If in fact there are no virtual terminals, its attempts to start shells on some virtual terminals later will fail anyway, so there is no need to disable virtual terminals outright.

After having initialized the console, BusyBox checks for the existence of an /etc/inittab file. If no such file exists, BusyBox uses a default inittab configuration. Mainly, it sets up default actions for system reboot, system halt, and init restart. Also, it sets up actions to start shells on the first four virtual consoles, /dev/tty1 through /dev/tty4. BusyBox will complain if you haven't created these device entries.

If an /etc/inittab file is found, it is parsed and the commands it contains are recorded inside internal structures to be carried out at the appropriate time. The format of the inittab file as recognized by BusyBox is well explained in the documentation included in the BusyBox package. The documentation provided in the BusyBox package includes an elaborate example inittab file.

Each line in the inittab file follows this format:


Although this format resembles that of traditional System V init, take note that the meaning of id is different in BusyBox init. Mainly, the id is used to specify the controlling tty for the process to be started. You can safely leave this entry empty if the process to be started isn't an interactive shell. Interactive shells, such as BusyBox's sh, should always have a controlling tty. BusyBox's sh will actually complain if it has no controlling tty. BusyBox completely ignores the runlevel field, so you can leave it blank. The process field specifies the path of the program to run, along with its command-line options. The action field is one of eight recognized actions to be applied to process as described in Table 6-6.

Table 6-6. Types of inittab actions recognized by BusyBox init



sys init

Provide init with the path to the initialization script.


Restart the process every time it terminates.


Similar to respawn, but is mainly useful for reducing the number of terminal applications running on the system. It prompts init to display "Please press Enter to activate this console." at the console and wait for the user to press Enter before restarting the process.

wai t

Tell init that it has to wait for the process to complete before continuing.

onc e

Run process only once without waiting for them.


Run process when the Ctrl-Alt-Delete key combination is pressed.


Run process when the system is shutting down.

res tart

Run process when init restarts. Usually, the process to be run here is init itself.

The following is a simple inittab file for my control module:

The following is a simple inittab file for my control module:

::sysinit:/etc/init.d/rcS ::respawn:/sbin/getty 115200 ttyS0 ::respawn:/control-module/bin/init ::restart:/sbin/init ::shutdown:/bin/umount -a -r

This inittab file does the following:

1. Sets /etc/init.d/rcS as the system initialization file.

2. Starts a login session on the serial port at 115200 bps.

3. Starts the control module's custom software initialization script.

4. Sets /sbin/init as the program to execute if init restarts.

5. Tells init to run the umount command to unmount all filesystems it can at system shutdown and set the others as read-only to preserve the filesystems.

The id is left blank in this case, because it doesn't matter to the normal operation of the commands. runlevel is also left blank, since it's completely ignored by BusyBox.

As shown earlier, however, none of these actions will take place until init runs the system initialization script. This script can be quite elaborate and can actually call other scripts. Use this script to set all the basic settings and initialize the various components of the system that need special handling. Particularly, this is a good place to:

• Remount the root filesystem in read-write mode.

• Mount additional filesystems.

• Initialize and start networking interfaces.

• Start system daemons.

Here is the initialization script for my control module: #!/bin/sh

# Remount the root filesystem in read-write (requires /etc/fstab) mount -n -o remount,rw /

# Mount /proc filesystem mount /proc

# Start the network interface /sbin/ifconfig eth0

The above initialization script depends on the existence of an /etc/fstab file in the target's root filesystem. I will not discuss the content and use of this file as it is already discussed in depth in Running Linux. Nevertheless, here's the /etc/fstab file I use for my control module during development:

# /etc/fstab

# device directory type options

/dev/nfs / nfs defaults none /proc proc defaults

In this case, I mount the target's root filesystem on NFS to simplify development. We will discuss filesystem types in Chapter 8 and NFS mounting in Chapter 9.

6.8.3 Minit

Minit is part of the miniaturized tools developed by Felix von Leitner, such as diet libc and embutils. Minit is available from http://www.fefe.de/minit/.[8] As with the other tools distributed by Felix, Minit requires a properly configured diet libc.

[8] As with the other tools available from fefe.de, the last slash ("/") is important.

Minit's initialization procedure is a complete departure from the traditional System V init. Instead of using a /etc/inittab, for instance, Minit relies on the existence of a properly built /etc/minit directory. Firdtjof Busse wrote a description of how Minit operates at http://www.fbunet.de/minit.shtml. Firdtjof also provides pointers to example /etc/minit directories.

Unfortunately, as of Version 0.8, Minit is not yet as mature as the other tools provided by Felix. Its Makefile, for instance, is unable to deal with installing the various components in a root filesystem other than the host's own. For the time being, Minit is not appropriate for an embedded system, but it may be worth considering sometime in the near future.

Continue reading here: Storage Device Manipulation

Was this article helpful?

+3 -1