What You Will Learn

Prerequisites

From Staging Directory to Bootable Target

A staging directory is just a normal directory tree on your build machine — it isn’t in any format a bootloader or kernel can consume directly. Getting it onto the target means picking one of three fundamentally different delivery mechanisms, each suited to a different stage of a project’s life:

Ramdisk: Fast, Simple, Volatile

A ramdisk is a filesystem image the bootloader loads directly into RAM before handing control to the kernel. Because it has no dependency on mass-storage drivers being initialized first, it’s the simplest possible way to get a shell running on brand-new hardware. Ramdisks are also commonly kept around as a fallback maintenance environment — if your main root filesystem gets corrupted during an update, a small ramdisk can still boot the board well enough to recover it. Some very small embedded devices even use a ramdisk as their permanent root filesystem, accepting the RAM cost in exchange for simplicity and robustness.

The trade-off is that everything in a ramdisk is volatile — the moment power is lost, any changes made at runtime disappear, along with the ramdisk itself. If your device needs to persist configuration or logs, you need a separate persistent storage mechanism alongside it.

Disk Image: The Production Default

A disk image is a pre-formatted copy of your staged root filesystem, ready to be written onto whatever mass storage your target uses — an ext4 image copied onto an SD card, or a jffs2/UBIFS image loaded into raw NAND flash via the bootloader, for example. This is by far the most common choice for shipped products, since it gives you a normal persistent filesystem with the usual expectations: files survive a reboot, logs accumulate, and configuration changes stick.

The specific image format you pick depends heavily on your storage hardware — SD/eMMC devices generally use conventional block filesystems like ext4, while raw NAND or NOR flash typically needs a flash-aware filesystem such as jffs2 or UBIFS that handles wear leveling and bad-block management itself.

Network Filesystem: Best for Active Development

During active development, rebuilding a disk image and reflashing it onto a physical storage device for every small change is slow and tedious. Exporting your staging directory from your development machine via an NFS server, and having the target mount it over Ethernet at boot time, sidesteps that entirely: you edit a file on your host, and the change is immediately visible to the running target on the next access, with no reflashing cycle at all.

This approach obviously requires a working network connection between host and target at boot time, and it’s rarely how a shipped product actually boots — but as a development-loop accelerator, it’s hard to beat, and most embedded Linux teams rely on it heavily before finalizing a disk-image-based release build.

Choosing the Right Method

• Bringing up brand-new hardware? Start with a minimal ramdisk — it has the fewest dependencies and gets you a shell fastest.
• Iterating on application or driver code daily? Use NFS root — skip the reflash cycle entirely while you work.
• Preparing something to actually ship? Build a disk image matched to your target’s real storage hardware and filesystem type.
• Need a recovery path in case the main rootfs breaks? Keep a small ramdisk around as a fallback boot option.

Many real projects end up using all three at different points: a ramdisk for early bring-up, NFS root for the bulk of development, and a disk image for the final production build — with the same staging directory feeding all three.

Getting Started: What a Boot Ramdisk Actually Is

Strictly speaking, a Linux boot ramdisk is called an initramfs (initial RAM filesystem), and under the hood it is nothing more exotic than a compressed cpio archive. cpio is an old Unix archive format — a contemporary of tar and zip — chosen for initramfs specifically because it’s simple enough to decode with very little code baked directly into the kernel itself, which matters when that decoding has to happen extremely early in the boot process, before almost anything else is running.

To use initramfs at all, your kernel needs to have been configured with the CONFIG_BLK_DEV_INITRD option enabled. You can confirm this on a target kernel with:

$ zcat /proc/config.gz | grep BLK_DEV_INITRD
CONFIG_BLK_DEV_INITRD=y

if /proc/config.gz is available on your system, or by checking the .config file used for your kernel build directly:

$ grep BLK_DEV_INITRD ~/linux/.config
CONFIG_BLK_DEV_INITRD=y

We’ll build a real initramfs from a staging directory — packing it with cpio, compressing it, and handing it to a bootloader — step by step in the next lecture. For now, the important mental model to walk away with is: an initramfs is just your staging directory, serialized into a single compressed archive that the bootloader loads straight into memory.

Common Mistakes and Troubleshooting

Best Practices

• Keep one staging directory as the single source of truth, and generate ramdisk/image/NFS export artifacts from it via your build scripts, rather than maintaining three diverging copies.
• Automate the transfer step (image creation, cpio packing, NFS export config) as part of your build pipeline so it’s reproducible.
• Test your fallback/rescue ramdisk periodically — a recovery path you’ve never actually tried is not a recovery path you can trust.

Performance Considerations

Ramdisks are typically the fastest to boot from, since RAM access beats any storage medium, but they consume RAM for the entire lifetime of the boot — a concern on memory-constrained boards. Disk images have the storage medium’s own read latency to contend with (NAND flash reads are markedly slower than RAM, though still fast enough for normal use). NFS root’s performance is bounded by your network link and the host’s disk speed, and adds a small amount of protocol overhead per file operation, which is usually irrelevant for development but would be a poor choice for a latency-sensitive production system.

Summary and Key Takeaways

• A staged root filesystem must be transferred to the target via one of three mechanisms: ramdisk, disk image, or network filesystem.
• Ramdisks (initramfs) load into RAM, have no mass-storage dependency, and are volatile — great for bring-up and rescue scenarios.
• Disk images are persistent and are the standard choice for production, formatted to match the target’s actual storage hardware.
• NFS root removes the reflash cycle during development but isn’t a realistic production deployment method.
• An initramfs is technically just a compressed cpio archive, and requires CONFIG_BLK_DEV_INITRD in the kernel configuration.

Conclusion

Choosing how to deliver your root filesystem to real hardware is as much a project-lifecycle decision as it is a technical one — ramdisks for bring-up and recovery, NFS for the development grind, and disk images for what actually ships. Understanding all three, and why each exists, is exactly the kind of practical judgment this free embedded systems course is designed to build. In the next lecture, we’ll roll up our sleeves and actually build a working initramfs from a staging directory, pack it with cpio, and boot it on real hardware.

Frequently Asked Questions