Rootfs

During development, many embedded Linux systems use a writable ext4 rootfs. It is convenient: copy missing files, edit configuration, and write logs under /var/log.

In a product, that convenience turns into risk:

• power loss can corrupt system files
• temporary files, logs, and databases get mixed into rootfs
• updates cannot easily tell user changes from system files
• factory reset has unclear boundaries
• the system partition becomes dirty, making field issues hard to reproduce

The point of a read-only rootfs is not simply to prevent changes. It is to make boundaries explicit: system files should be verifiable and recoverable; runtime state should be disposable; user data should have a clear home; updates and factory reset should not guess which files matter.

Many embedded Linux projects start by assembling a system by hand: download a cross compiler, build the kernel, copy BusyBox, add libraries, package rootfs, and drop in the application.

That may boot a board, but it quickly breaks down in a product:

• which cross toolchain built this image
• which kernel config and device tree were used
• where each library in rootfs came from
• why the same application links differently on another machine
• whether production images, debug images, and SDKs can be generated from one configuration
• whether the same system can be rebuilt six months later

Buildroot and Yocto do not mainly solve “how to install a few packages”. They solve this: how to put the toolchain, bootloader, kernel, rootfs, packages, image, and SDK into a repeatable build system.

The serial log may show a long Linux kernel boot, then end in a panic. The kernel may appear to boot, but the product application never starts. The log may say No working init found or VFS: Unable to mount root fs.

These failures are often treated as application startup problems. But before any application can run, Linux has to cross a more basic boundary: the kernel must find and mount rootfs, then execute the first user-space process.

When an embedded Linux device boots slowly, an application does not start, a driver does not load, or a network service fails, people often jump straight to application logs.

But the application is only the last part of the boot chain. After power-on, the CPU does not directly jump to business logic. It starts from a fixed entry, initializes the minimal hardware environment, enters the bootloader, loads the Linux kernel, Device Tree, and rootfs-related information, waits for the kernel to reach user space, and only then reaches the application.