The inittab File Format

BusyBox init is deliberately small — it has no daemon dependency graph, no unit files, just one configuration file it reads once at startup: /etc/inittab. Each non-comment line follows a fixed four-field format:

<id>::<action>:<program>

• id — the controlling terminal for the command (often left blank for non-terminal actions).
• action — the condition under which BusyBox init runs this line (see table below).
• program — the actual command or script to execute.

Every Action Keyword, Explained

Building an Original inittab

Here’s a minimal but complete example for a board that mounts the essentials, brings up a device manager, and gives you a login shell — none of it copied from any reference book, just a straightforward setup you’d actually use:

# /etc/inittab
::sysinit:/bin/mount -t proc proc /proc
::sysinit:/bin/mount -t sysfs sysfs /sys
::sysinit:/bin/mount -t devtmpfs devtmpfs /dev
::sysinit:/etc/init.d/rcS
ttyS0::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r

The sysinit lines run first, in order, so the mounts happen before rcS tries to use /dev. The askfirst line waits for you to press Enter on the serial console before dropping into a shell — handy so you’re not fighting boot log spam for control of the terminal.

Making It Extensible: rcS and rcK

A single flat inittab gets unwieldy fast once you have more than a couple of daemons. That’s the problem Buildroot’s rcS/rcK pattern solves. Instead of listing every startup step directly in inittab, you point sysinit at one script, /etc/init.d/rcS, which then iterates over every executable in /etc/init.d/ whose name starts with a capital S followed by two digits — running them in numerical order. A matching rcK script does the same for files starting with K at shutdown.

# /etc/init.d/S01ep_mountfs
#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys

# /etc/init.d/S02ep_network
#!/bin/sh
ip link set eth0 up
udhcpc -i eth0 -b

# /etc/init.d/S10ep_myapp
#!/bin/sh
/usr/bin/ep_sensor_daemon &

# /etc/init.d/K10ep_myapp
#!/bin/sh
killall ep_sensor_daemon

Because the two-digit prefix controls ordering, adding a new package’s startup step is just a matter of dropping in a new S/K file with an appropriate number — no editing of a growing monolithic script required.

Build and Boot Walkthrough

To see this in action, rebuild your root filesystem with the inittab above and an S10ep_myapp script that just echoes a message, then boot in QEMU:

$ make menuconfig   # ensure BusyBox init is selected, not systemd
$ make
$ qemu-system-arm -M vexpress-a9 -kernel output/images/zImage \
    -dtb output/images/*.dtb -drive file=output/images/rootfs.ext4,if=sd \
    -append "console=ttyAMA0 root=/dev/mmcblk0" -nographic

Expected output on the console:

[    1.812340] Run /sbin/init as init process
Starting rcS...
[ep_mountfs] proc and sysfs mounted
[ep_network] eth0 up, requesting DHCP lease
[ep_myapp] sensor daemon started, pid 118
Please press Enter to activate this console

If instead the board hangs right after “Run /sbin/init as init process” with no further output, the most common cause is a syntax error in inittab or a missing #!/bin/sh shebang on one of the rcS scripts.

Common Mistakes

Best Practices

Summary and Key Takeaways

• BusyBox init reads one file, /etc/inittab, with a simple id::action:program format.
• Eight action keywords cover everything from one-shot setup to respawned daemons to signal-triggered handlers.
• Buildroot’s rcS/rcK convention turns a flat inittab into an extensible, numerically-ordered startup system used by every installed package.

Frequently Asked Questions