What You Will Learn

Prerequisites

This lecture assumes you have a staged rootfs directory from earlier in this free embedded systems course, and are comfortable with basic device node concepts (major/minor numbers, node types) from the device-node lecture earlier in this chapter.

The Root Problem: mknod Needs root

If you try to bake device nodes directly into a filesystem image as an ordinary CI user, mknod fails outright — creating a character or block special file is a privileged operation by design, since it lets a process grant itself arbitrary access to physical devices or kernel interfaces. Historically this forced build systems to either run parts of the build as root inside a container, or use fakeroot-style wrapping. Device tables sidestep the problem entirely: instead of creating nodes on the host filesystem at all, you describe them in a text file, and a purpose-built tool bakes the corresponding entries directly into the output image format, with no privileged syscall required on the build host.

The Device Table Format

A device table is a plain text file, one line per entry, with this field layout:

<name> <type> <mode> <uid> <gid> <major> <minor> <start> <inc> <count>

Fields that do not apply to a given type (major/minor for a plain file, for instance) are simply written as -.

A Worked Example

Here is a small, original device table covering a handful of common nodes plus a numbered range for serial ports:

# ep_device_table - example device table for a minimal rootfs
# name          type mode  uid  gid  major minor start inc count
/dev            d    755   0    0    -     -     -     -   -
/dev/console    c    600   0    0    5     1     -     -   -
/dev/null       c    666   0    0    1     3     -     -   -
/dev/zero       c    666   0    0    1     5     -     -   -
/dev/ttyS       c    660   0    0    4     64    0     1   4

The last line generates four nodes in one entry — ttyS0 through ttyS3 — with minor numbers starting at 64 and incrementing by 1 for each, which is far less error-prone than writing four separate lines by hand.

Building an initramfs with gen_init_cpio

The Linux kernel source tree ships a small standalone tool, gen_init_cpio, specifically for turning a device table (plus a file list) into a cpio archive suitable for use as an initramfs. It lives under usr/ in the kernel source and can be built independently of a full kernel build:

$ gcc -O2 -o gen_init_cpio linux/usr/gen_init_cpio.c
$ ./gen_init_cpio ep_device_table.txt > rootfs.cpio

gen_init_cpio also accepts file and dir lines in the same table so you can describe your entire image — regular files pulled from the staging tree, directories, and device nodes — in one declarative document, all without touching a privileged syscall:

dir  /bin      755 0 0
file /bin/busybox staging/bin/busybox 755 0 0
dir  /dev      755 0 0
nod  /dev/console 600 0 0 c 5 1

The Same Pattern for Other Filesystem Formats

gen_init_cpio is not unique — the same device-table concept has been adopted by the image builders for the other filesystem formats commonly used on embedded flash storage and disk:

Each of these tools accepts a device table via a -D flag (the exact flag name varies slightly by tool) and applies the same field layout described above. We cover jffs2 and ubifs in depth later in this course when we look at flash storage strategies; genext2fs follows the identical device table syntax for building disk-based images.

Common Mistakes and Troubleshooting

• Mismatched major/minor numbers — a device table entry with the wrong major/minor creates a node that looks correct with ls -l but talks to the wrong driver, or none at all.
• Forgetting the type column entirely — a missing or malformed type field causes most tools to reject the whole table rather than skip one bad line.
• Using device tables for devices that should be dynamic — baking hotplug-capable devices (USB, SD card readers) into a static table defeats the point of devtmpfs/mdev covered earlier in this chapter; reserve device tables for nodes that genuinely never change.
• Path mismatches between the table and the staged files list — when combining file and device entries in one table, a typo in a source path fails the whole build, not just that one line.

Best Practices

Keep device tables under version control next to the rest of your rootfs build scripts, and comment each line with the device it corresponds to — the field-only format is not self-explanatory months later. Prefer device tables only for genuinely static, always-present nodes (console, null, zero); leave hotplug-capable hardware to devtmpfs and mdev from the earlier lecture in this chapter.

Summary and Key Takeaways

Device tables let you describe device nodes declaratively in plain text and have a build tool create them inside a filesystem image, entirely avoiding the need for root privileges on the build host. The same field format is shared across gen_init_cpio, mkfs.jffs2, mkfs.ubifs, and genext2fs, making it a single skill that applies across nearly every embedded filesystem format.

Conclusion

Device tables are a small, easily overlooked tool, but they solve a real and common build-pipeline problem cleanly. Once you understand the field layout, the same technique carries across every major embedded filesystem format covered in this free linux kernel development course, from a simple initramfs to a production jffs2 or ext2 image.

Frequently Asked Questions