Mastering Linux Root Filesystem: Theory, BusyBox Build, and NFS Boot

1. Linux Root Filesystem Fundamentals

The kernel requires a root filesystem (rootfs) that provides the / directory, essential binaries ( /bin, /sbin), libraries ( /lib), and configuration files ( /etc). The init process and shell utilities reside on this filesystem, making kernel + rootfs a complete Linux distribution.

1.1 Why a Rootfs Is Required

The init process is launched from the rootfs.

The root directory / is supplied by the rootfs.

Runtime configuration files (e.g., /etc) and user commands ( ls, cd) live on the rootfs.

Without these components the kernel cannot function.

1.2 Nature of the Rootfs

It is a special‑purpose filesystem that must be formatted with a known type (ext2/3/4, jffs2, etc.).

Block devices store raw sectors; the filesystem translates sector accesses into directory and file operations.

1.3 Forms of Rootfs

Image file created by dedicated tools (e.g., mke2fs, mkfs.jffs2).

Folder‑style rootfs: a directory on the host that contains the required files; it can be exported via NFS or turned into an image.

1.4 Building a Simple Ext3 Rootfs

Steps to create a blank ext3 image, populate it, and detach the loop device:

Create a zero‑filled file and associate it with a loop device, then format it:

Add a placeholder linuxrc (initially non‑functional) to test mounting.

Unmount and detach the loop device:

1.5 NFS‑Based Rootfs

Export a folder‑style rootfs from a host via NFS and configure the kernel to mount it at boot:

Install and configure an NFS server on Ubuntu (e.g., apt-get install nfs-kernel-server) and export the rootfs directory.

Enable CONFIG_ROOT_NFS in the kernel (

make menuconfig → File systems → NFS client support → Root filesystem over NFS

).

Pass boot arguments, for example:

The kernel mounts the NFS export and attempts to execute /linuxrc. Replace the placeholder with a real BusyBox‑based linuxrc to complete the boot.

2. Building a Minimal Rootfs with BusyBox

2.1 Porting BusyBox

Download the source from https://busybox.net (any recent stable version).

Edit the top‑level Makefile to set the target architecture and cross‑compiler prefix, e.g.:

Run make menuconfig and enable:

Build BusyBox as a static binary (no shared libs).

Desired applets (vi‑style editing, mdev, networking utilities, etc.).

Compile and install into a staging directory:

2.2 Inittab Format

BusyBox init parses /etc/inittab entries of the form id:runlevels:action:process. Important fields:

action – condition that triggers the process (e.g., sysinit, respawn, once).

process – executable pathname.

During boot BusyBox executes sysinit, wait, and once once, then repeatedly handles respawn and askfirst in a loop.

3. BusyBox Source Overview

3.1 Entry Point

The real entry point is libbb/appletlib.c. Its main() dispatches to the appropriate applet based on argv[0] (e.g., ls_main, sh_main).

3.2 Size Advantage

Each applet implements a trimmed‑down command set, reducing code size.

Common functionality (argument parsing, file handling) is shared among applets, avoiding duplication.

4. rcS Script and Runtime Configuration

The script /etc/init.d/rcS is executed early by BusyBox init. Typical actions:

Export PATH (e.g., /bin:/sbin:/usr/bin:/usr/sbin) and runlevel=S.

Set umask (e.g., 022 → default file mode 644).

Run mount -a to mount filesystems listed in /etc/fstab (proc, sysfs, tmpfs, etc.).

Start mdev to populate /dev with device nodes.

Configure hostname and network interface (e.g., ifconfig eth0 192.168.1.88).

Common pitfalls:

Windows line endings ( \r\n) cause the script to be reported as missing; convert to Unix LF.

Missing mount points (e.g., /proc) result in errors like

mount: mounting proc on /proc failed: No such file or directory

. Create the directories before mounting.

5. Adding Dynamic Libraries to the Rootfs

When compiling a program dynamically (e.g., arm-linux-gcc hello.c -o hello_dynamic), the resulting ELF expects shared libraries such as libc.so to be present in /lib on the target.

# Find the required libraries in the cross‑compiler sysroot
find /usr/local/arm/arm-2009q3/arm-none-linux-gnueabi/libc/lib -name "*lib*.so*"
# Copy them preserving symlinks
cp -a lib/* /path/to/rootfs/lib/

Strip symbols from the copied .so files to save space:

arm-none-linux-gnueabi-strip *.so

6. Creating an Ext2 Image and Flashing

dd if=/dev/zero of=rootfs.ext2 bs=1024 count=10240
losetup /dev/loop1 rootfs.ext2
mke2fs -m 0 /dev/loop1 10240
mount -t ext2 /dev/loop1 ./ext2_rootfs/
cp -a ../rootfs/* ./ext2_rootfs/ -r
umount /dev/loop1
losetup -d /dev/loop1

Flash the image to the target device (e.g., via fastboot): fastboot flash system rootfs.ext2 Boot arguments for an ext2 rootfs on an MMC device:

set bootargs console=ttySAC2,115200 root=/dev/mmcblk0p2 rw init=/linuxrc rootfstype=ext2

7. BSP Overview for Embedded Linux

A typical ARM BSP contains:

Bootloaders (e.g., xboot, u‑boot).

Linux kernel source tree. buildroot directory for rootfs generation.

A helper script mk that orchestrates builds:

8. Buildroot Introduction

Buildroot automates cross‑toolchain creation and rootfs assembly.

Select a defconfig for the target board (e.g., make x210ii_defconfig).

Fine‑tune options with make menuconfig (select BusyBox, kernel version, filesystem type, etc.).

Run make. The resulting tarball output/images/rootfs.tar contains a ready‑to‑use folder‑style rootfs.

Required host packages: g++ bison flex texinfo git subversion whois.

The generated rootfs can be extracted, packaged into an image, flashed, or exported via NFS for development.