ES: Root Filesystem in Embedded Linux

After the Linux kernel boots and the device tree is processed, the kernel needs a root filesystem to mount. Without it, the system cannot start the init process, cannot run system programs, and cannot launch the application. The root filesystem is the top of the embedded Linux software stack — everything the running system depends on.

What is the Root Filesystem?

The root filesystem is a special filesystem that the Linux kernel mounts at startup at the root path /. It contains:

• Configuration files — how the system prepares the execution environment (e.g. network interface addresses, timezone, hostname)
• The init process — the first user-space process started by the kernel
• System programs — utilities like shells, daemons, and tools
• Shared libraries — runtime dependencies for all programs
• Device nodes — files in /dev representing hardware devices
• Kernel modules — loadable .ko files in /lib/modules/

Kernel boots
    |
    | mounts root filesystem
    v
/init or /sbin/init starts
    |
    v
System configured and running
    |
    v
Application launched

The kernel does not know anything about the root filesystem contents — it only looks for the `init` program specified on the kernel command line. The design decision to decouple kernel from root filesystem is intentional.

Loading the Root Filesystem

There are two primary methods to provide the root filesystem to the kernel:

initramfs (Initial RAM Filesystem)

The root filesystem is embedded in the kernel image or passed as a separate archive. It is extracted entirely into RAM at boot time.

Use cases:

• Setup environments before mounting the real root filesystem
• Loading modules needed to access the real storage
• Very small embedded systems that fit entirely in RAM

Bootloader
    |
    | loads kernel + initramfs archive
    v
Kernel extracts initramfs into RAM
    |
    v
/init script runs (from initramfs)
    |
    v
Mounts real root filesystem (optional)

Block Device

The root filesystem resides on a persistent block device — an SD card, eMMC chip, NAND flash, or HDD.

The kernel is told which device to mount via the kernel command line:

root=/dev/mmcblk0p2 rootfstype=ext4

The kernel mounts the specified device as the root filesystem.

Root Filesystem Hierarchy Standard (FHS)

The Filesystem Hierarchy Standard (FHS) defines the content and purpose of each directory in the root filesystem:

Minimal Root Filesystem Layout

/
├── bin/                    # Essential user binaries
├── lib/                    # Shared libraries
├── dev/
│   ├── console c 5 1       # Console device
│   ├── null c 1 3          # Null device
│   ├── zero c 1 5          # Zero device
│   ├── tty c 5 0           # TTY device
│   └── ttyS0 c 4 64        # Serial console
├── etc/
│   ├── inittab             # Init configuration
│   └── init.d/
│       └── rcS             # System init script
├── proc/                   # Process virtual filesystem
├── sbin/                   # System admin binaries
├── sys/                    # System virtual filesystem
├── tmp/                    # Temporary files
├── usr/                    # Additional programs
└── var/                    # Runtime variable data

Root Filesystem Contents in Detail

init

The first user-space process started by the kernel. It reads an init configuration (e.g. /etc/inittab) and starts all system services and daemons.

Shell

A command interpreter that runs shell scripts and handles interactive sessions. In embedded Linux, typically provided by BusyBox ash or sh.

Daemons

Background processes that provide services:

• syslogd — system logging
• udevd — device node management
• dhcpcd — network configuration

Shared Libraries

All programs dynamically linked against glibc or other libraries need those libraries present in /lib and /usr/lib.

Device Nodes

Files in /dev that represent hardware. In modern Linux, these are created dynamically by udev. For minimal systems without udev, a static /dev can be used.

BusyBox: The Embedded Root Filesystem Workhorse

BusyBox is a single binary that implements hundreds of standard Unix utilities. It is the standard choice for the system programs component of an embedded root filesystem.

Without BusyBox:
  /bin/ls  /bin/cat  /bin/sh  /bin/grep  ...  (many binaries)
  Total: several MB

With BusyBox:
  /bin/busybox  (single binary ~500KB)
  /bin/ls    -> busybox  (symlink)
  /bin/cat   -> busybox  (symlink)
  /bin/sh    -> busybox  (symlink)
  /bin/grep  -> busybox  (symlink)

To identify BusyBox's runtime dependencies for the target:

aarch64-none-linux-gnu-readelf -a /bin/busybox | grep "program interpreter"
aarch64-none-linux-gnu-readelf -a /bin/busybox | grep "Shared library"

Root Filesystem Location Options

The root filesystem can be stored in different locations depending on the product requirements:

Network Root Filesystem (NFS)

During development, mounting the root filesystem over NFS from the host machine is extremely productive:

Host machine (NFS server)
    |
    | NFS over Ethernet
    v
Target board (NFS client)

Changes to the root filesystem on the host are immediately visible on the target without reflashing.

Using the Root Filesystem with Target Hardware

There are three practical ways to deploy a root filesystem to a target device:

Writing a Disk Image

sudo dd if=rootfs.ext4 of=/dev/mmcblk0 bs=1M
sync

Final Thoughts

The root filesystem is the living environment of the embedded Linux system. Every program that runs, every configuration that is read, and every log that is written happens within the root filesystem.

Root Filesystem Design Checklist:
Include only needed programs (use BusyBox)
    |
    v
Include all required shared libraries
    |
    v
Create necessary device nodes
    |
    v
Configure /etc/inittab or systemd services
    |
    v
Test the minimal system before adding application
    |
    v
Deploy via disk image, ramdisk, or NFS

A well-designed embedded root filesystem is lean, correct, and reliable — containing exactly what the system needs and nothing it does not.