What You Will Learn

Prerequisites

What a Standalone Initramfs Actually Is

An initramfs is nothing more exotic than a directory tree serialized into a single stream of bytes, using the cpio archive format, and handed to the kernel at boot time. The kernel unpacks that stream directly into a RAM-backed filesystem before any real block device driver has even been probed. That’s the whole trick — the initramfs exists entirely in memory, so the kernel doesn’t need a disk, an SD card, or a network stack ready in order to boot into a usable shell.

There are three broad ways to get an initramfs into a running kernel:

This lecture covers option one — the standalone archive — because it’s the fastest way to iterate: rebuild the rootfs, regenerate the archive, and reboot, without ever touching the kernel image itself. The next lecture in this free embedded Linux course covers baking initramfs directly into the kernel, which matters when your bootloader can’t load a second file at all.

Packing the Rootfs Into a Cpio Archive

Assuming your staged rootfs lives in ~/ep-rootfs, here is the sequence to pack, compress, and prepare it for booting:

$ cd ~/ep-rootfs
$ find . | cpio -H newc -ov --owner root:root > ../ep-initramfs.cpio
$ cd ..
$ gzip ep-initramfs.cpio
$ ls -lh ep-initramfs.cpio.gz

Two details here matter more than they look:

• -H newc selects the “new ASCII” cpio format, which is what the kernel’s initramfs unpacker expects. Older cpio variants will simply fail to extract.
• –owner root:root forces every file in the archive to UID/GID 0, regardless of who actually owns the files on your build host. Without this flag, files you staged as your own non-root user would end up owned by your host UID inside the booted rootfs — which is rarely what you want, and can break setuid tooling like BusyBox’s login applets.

If your bootloader needs a wrapped image (common with U-Boot-based boards), add a header on top of the gzipped archive:

$ mkimage -A arm64 -O linux -T ramdisk -d ep-initramfs.cpio.gz ep-uRamdisk

If you’re only testing under QEMU, you can skip mkimage entirely and hand the gzipped cpio straight to QEMU’s -initrd option, which we’ll do below.

Sizing the Archive

A minimal BusyBox-based rootfs with no kernel modules typically compresses down to a few megabytes. Once you add a real kernel Image and a bootloader on top, total flash or storage requirements climb quickly — which matters a lot on resource-constrained boards. If storage is tight, you have several practical levers:

Telling the Kernel What to Run First: rdinit=

Once the kernel has unpacked the archive into memory, it needs to know what program to execute as PID 1. For a standalone initramfs, that’s the job of the rdinit= kernel command-line parameter. The simplest possible value is a shell:

rdinit=/bin/sh

This drops you straight into an interactive shell running as PID 1 — extremely useful for early bring-up and for rescuing a board whose real init program is broken, but not something you’d ship in production.

Booting Under QEMU

QEMU’s ARM64 virt machine is the fastest way to test an initramfs without any real hardware. The -initrd option loads the compressed cpio archive directly into memory alongside the kernel:

$ qemu-system-aarch64 -M virt -cpu cortex-a72 -m 512M -nographic \
  -kernel Image \
  -initrd ep-initramfs.cpio.gz \
  -append "console=ttyAMA0 rdinit=/bin/sh"

Expected output on a successful boot:

[    0.912340] Run /bin/sh as init process
/ # 

You now have an interactive root shell running entirely out of RAM. Type exit or press Ctrl-A then X to leave QEMU.

Booting on Real Hardware via U-Boot

On a board running U-Boot, the equivalent sequence loads the kernel, device tree, and the wrapped ramdisk into RAM addresses appropriate for your board, then boots:

=> fatload mmc 0:1 0x40200000 Image
=> fatload mmc 0:1 0x43000000 ep-board.dtb
=> fatload mmc 0:1 0x44000000 ep-uRamdisk
=> setenv bootargs console=ttyS0,115200 rdinit=/bin/sh
=> booti 0x40200000 0x44000000 0x43000000

The exact load addresses and console name depend entirely on your board’s memory map and UART — always check your board’s reference manual rather than copying addresses from someone else’s board.

Mounting proc: Why ps Doesn’t Work Yet

The first thing most people try in a fresh initramfs shell is ps, and the first thing that happens is it fails or prints nothing useful. That’s because /proc is a pseudo-filesystem that the kernel populates on demand — it has to be mounted explicitly, it isn’t there automatically just because the rootfs booted.

/ # ps
ps: can't open '/proc': No such file or directory
/ # mount -t proc proc /proc
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /bin/sh

Writing a Real Init Script

Booting straight to a bare shell is fine for a five-minute experiment, but any serious board bring-up should run a small init script instead — it’s the natural next step before you eventually adopt a real init system. Point rdinit= at a script rather than at /bin/sh directly:

#!/bin/sh
# ep_init.sh — minimal early-boot script
mount -t proc proc /proc
mount -t sysfs sysfs /sys
echo "ep-rootfs: early mounts complete"
exec /bin/sh

$ chmod +x ~/ep-rootfs/ep_init.sh
$ qemu-system-aarch64 -M virt -cpu cortex-a72 -m 512M -nographic \
  -kernel Image \
  -initrd ep-initramfs.cpio.gz \
  -append "console=ttyAMA0 rdinit=/ep_init.sh"

This one small change — mounting proc and sysfs before dropping to a shell — is exactly the kind of habit that separates a quick hack from a bring-up environment you can actually debug in.

Common Mistakes and Troubleshooting

Best Practices

Summary and Key Takeaways

A standalone initramfs is just a cpio archive of your staged rootfs, gzipped, and handed to the kernel via the bootloader. The rdinit= parameter tells the kernel what to run as PID 1 once that archive is unpacked into RAM. This workflow is deliberately the fastest to iterate on in any free embedded Linux course, because rebuilding the rootfs never requires rebuilding the kernel — you only regenerate the archive. In the next lecture of this free linux kernel development course, we bake the same content directly into the kernel image for bootloaders that can’t load a second file.

Frequently Asked Questions