The root filesystem (rootfs) is the top-level filesystem mounted at '/' during Linux boot, containing the directory tree, libraries, binaries, configuration files, and device nodes that a running Linux system depends on. On embedded targets it is typically a purpose-built, minimal image rather than a general-purpose desktop distribution.
In practice
On embedded Linux systems the rootfs is almost always custom-built using a tool such as Buildroot, Yocto/OpenEmbedded, or assembled by hand from a BusyBox-based userland. The resulting image may be stored in NAND/NOR flash, an SD card, eMMC, or even a network share (NFS), and the bootloader or kernel is told where to find it via a kernel command-line argument such as 'root=/dev/mmcblk0p2' or 'root=/dev/mtdblock2'. As described in "An overview of Linux Boot Process for Embedded Systems" and "Boot Sequence for an ARM based embedded system," mounting the rootfs is one of the final steps before the kernel hands control to init (or systemd, BusyBox init, etc.).
The rootfs format depends on the storage medium and memory constraints. Common choices include ext4 on block devices (SD/eMMC), JFFS2 or UBIFS on raw NAND flash, and SquashFS (read-only, compressed) when flash space is tight or filesystem corruption from power loss must be avoided. A compressed initramfs (a rootfs image embedded directly in the kernel image or loaded by the bootloader) is also a common choice on targets with limited or no persistent storage, though such systems may use the initramfs as the entire root filesystem or employ other boot strategies entirely.
A frequent mistake on constrained targets is including unnecessary libraries, debug tools, or locale data, inflating the image size and attack surface. BusyBox -- covered in "BusyBox; The Swiss Army Knife of Embedded Linux" -- is a widely used solution for providing a full suite of Unix utilities in a single small binary, and forms the backbone of many embedded rootfs builds. Buildroot and Yocto automate dependency tracking and cross-compilation to produce a consistent, reproducible image.
Getting the rootfs wrong is a common source of hard-to-diagnose boot failures. A mismatch between the kernel version and a kernel module in the rootfs, a missing /dev node, or a corrupt flash partition can all cause a kernel panic at mount time or a silent hang at init. "Dumb Embedded System Mistakes: Running The Wrong Code" highlights how running a mismatched rootfs image -- for example, leaving an old image in flash while testing a new kernel -- can waste significant debug time.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between an initramfs and a rootfs?
An initramfs (initial
RAM filesystem) is a temporary rootfs loaded into RAM early in the boot process, typically used to perform tasks such as loading drivers or decrypting a partition before the real rootfs is mounted. On many embedded targets with simple storage the initramfs is also the permanent rootfs -- the system runs entirely from RAM, which simplifies write-protection and avoids filesystem corruption from unexpected power loss.
Which rootfs filesystem format should I use for NAND flash?
UBIFS is generally the preferred choice for raw
NAND flash on modern embedded Linux systems because it handles
wear leveling (via UBI), bad block management, and power-cut safety. JFFS2 is an older alternative that works but scales poorly on large
flash devices due to long mount times caused by scanning the entire partition. SquashFS over UBI (with a separate writable overlay) is common when a read-only rootfs is acceptable.
How does the kernel know where the rootfs is?
The kernel receives the rootfs location via the 'root=' parameter on the kernel command line, which is typically set by the
bootloader (U-Boot, for example, passes it through the 'bootargs' environment variable). The value can reference a block device path (root=/dev/sda1, root=/dev/mmcblk0p2), a PARTUUID, or a network path for NFS root. If the rootfs is an initramfs linked into the kernel image, no 'root=' argument pointing to a block device is typically needed -- the kernel mounts the embedded image automatically, though boot parameters may still matter if the system later pivots to another root.
What causes a 'kernel panic: not syncing: VFS: unable to mount root fs' error?
This panic means the kernel could not mount the rootfs. Common causes include: the 'root=' argument points to a device that does not exist or is not yet initialized when the kernel attempts the mount; the required storage driver or filesystem driver was not compiled in (or not loaded from initramfs); the partition table or
flash layout does not match what the kernel expects; or the filesystem image is corrupt. Checking the full kernel boot log and verifying that the rootfs partition is visible in the kernel's device list (/proc/partitions or early printk output) are the first diagnostic steps.
Do I need a package manager in an embedded rootfs?
Typically no. Most embedded rootfs images are built offline using Buildroot or Yocto, producing a fixed set of packages compiled for the target. Shipping a package manager (apt, rpm, opkg) adds size and complexity, and updating packages independently of the rest of the firmware can introduce version mismatches. opkg is used on some platforms (OpenWrt, for example) where in-field package installation is a product requirement, but it is the exception rather than the rule in tightly controlled embedded deployments.
Differentiators vs similar concepts
The rootfs is sometimes confused with the initramfs. In typical embedded Linux usage, the rootfs is the fully operational filesystem the system runs from; however, the term is also used in Linux more broadly to refer to any initial root filesystem mounted by the kernel, including the temporary
RAM-backed root used before switching to another root. The initramfs is specifically an early temporary filesystem used during boot to prepare the environment before the real rootfs is mounted. On simple embedded systems the initramfs may serve as the permanent rootfs, but the two concepts are distinct. The rootfs is also distinct from the kernel image itself -- the two are separate artifacts, often stored in separate
flash partitions, even though they must be compatible with each other.
