What You Will Learn

Prerequisites

From Kernel Boot to a Shell Prompt

Embedded Linux is really four separate pieces working together: a bootloader, a kernel, a toolchain that built everything, and a root filesystem. The first three get a board to the point where the kernel is running in memory — but a running kernel with nothing to execute is not a usable device. The kernel’s very last job during boot is to locate a root filesystem, mount it, and hand control to a single program inside it. Everything that happens after that point — networking, logging, your application logic — is the root filesystem’s responsibility, not the kernel’s.

The kernel locates the root filesystem in one of two ways. Either it is told about a block device using the root= kernel command-line parameter, or it is handed a ramdisk image directly by the bootloader. Once mounted, the kernel looks for a program to execute — by default named init — and that single act completes the kernel’s involvement in booting. From that instant on, every process on the system is a descendant of that first program, traditionally running as process ID 1.

The Minimum Set of Components

A root filesystem that only contains an init program is not very useful. To get a genuinely usable embedded system, a handful of categories of content need to exist together:

On top of this baseline sit the actual application(s) that make your device do its job, plus whatever runtime data those applications generate or consume. A retail barcode scanner, an industrial gateway, and a smart thermostat all share the same eight-item skeleton above — what differs is the application layer bolted on top of it.

Collapsing Everything Into One Program

It is worth knowing that the kernel does not actually require any of the categories above except “a program to run.” Nothing stops you from statically linking a single binary that does absolutely everything — reads sensors, drives a display, handles networking — and telling the kernel to run only that. You would point the kernel at it directly on the command line instead of the conventional init path.

This “single statically linked program” approach trades away every convenience tool that a conventional root filesystem gives you — no shell to debug with, no standard utilities, nothing. It is rarely the right choice for production, but understanding that it is possible makes the rest of this chapter click: everything else we build is really just infrastructure layered on top of “the kernel runs one program.”

Hands-On: Watching init= Change Boot Behavior

Let’s prove the handoff mechanism to ourselves using QEMU instead of real hardware, so this works on any Linux host. We will build a tiny statically linked program called ep_init and boot a kernel straight into it, bypassing a conventional root filesystem entirely.

$ cat > ep_init.c << 'EOF'
#include <unistd.h>
#include <sys/reboot.h>

int main(void)
{
    write(1, "ep_init: I am PID 1, running as the only program\n", 51);
    while (1)
        pause();
    return 0;
}
EOF

$ gcc -static -o ep_init ep_init.c
$ file ep_init

# Expected output:
ep_init: ELF 64-bit LSB executable, x86-64, statically linked, ...

Package that single binary into a minimal initramfs cpio archive:

$ mkdir ep_initramfs
$ cp ep_init ep_initramfs/
$ cd ep_initramfs
$ find . | cpio -H newc -o > ../ep_initramfs.cpio
$ cd ..

Now boot a stock kernel image in QEMU, pointing directly at our program with rdinit=:

$ qemu-system-x86_64 -kernel bzImage \
    -initrd ep_initramfs.cpio \
    -append "console=ttyS0 rdinit=/ep_init" \
    -nographic

# Expected console output (tail):
...
Run /ep_init as init process
ep_init: I am PID 1, running as the only program

Notice the kernel log line Run /ep_init as init process — that is the exact moment the kernel’s job ends and ours begins. Everything you build for the rest of this chapter is really about making that first program smarter: instead of an infinite pause loop, it will mount /proc and /sys, start a shell, and bring up services.

Real-World Use Cases

• Full conventional rootfs — general-purpose gateways, industrial HMIs, and anything with a shell-based debug workflow
• Ramdisk-only rootfs — recovery images, installer environments, and systems that boot from a read-only NOR flash bootloader
• Single-static-binary init — ultra-constrained RAM budgets, secure appliances that must expose zero shell access, and fast-boot demo hardware

Common Mistakes and Troubleshooting

Best Practices

• Keep your very first init program dead simple and statically linked while you are bringing up new hardware — swap in a full init system only once basic boot is proven.
• Always test with rdinit= against a ramdisk before committing to a block-device root filesystem; it is far faster to iterate on.
• Log early boot output to a serial console — once /proc and syslog exist you have better tools, but you need visibility before that.

Security Considerations

A statically linked, minimal init reduces your attack surface dramatically compared to a full init system pulling in dozens of shared libraries at boot. If a device genuinely never needs an interactive shell in production, consider shipping it with no shell binary in the rootfs at all rather than merely restricting access to one.

Summary and Key Takeaways

• The kernel’s last boot responsibility is mounting a root filesystem and executing one program — everything after that is user space.
• A genuinely usable root filesystem needs init, a shell, daemons, shared libraries, configuration files, device nodes, /proc and /sys, and any kernel modules.
• init= and rdinit= let you point the kernel at any program, proving that the “root filesystem” concept is really just “whatever PID 1 needs to do its job.”
• PID 1 must never exit, or the kernel will panic.

Conclusion

Understanding the root filesystem as “the minimum set of things PID 1 needs” rather than “a mysterious directory tree” makes the rest of this free Linux kernel development course chapter far easier to follow. In the next lecture we will look at the Filesystem Hierarchy Standard and start staging a real, conventional root filesystem directory by directory.

Frequently Asked Questions