Buildroot's two-command ARM image, and the directory that will brick your board

Buildroot cannot create the device nodes under `/dev`, and it cannot set the setuid bit on the BusyBox binary ^[7][8]. Both gaps have one cause: it runs as an ordinary user, and neither operation is available to one ^[6]. So `output/target` ends up holding the right files with the wrong metadata, and metadata is what init and every setuid helper on the system actually consume. Flash from that tree and the board comes up wrong rather than not at all ^[8], which is the expensive outcome, because it survives a casual smoke test and reaches somebody else's desk.

The documented way out is a tarball. If you need an unpacked root filesystem, for an NFS root say, build the tar image in `output/images` and extract it as root ^[9]. That confines the privileged step to the end, where the ownership and permission bits recorded in the archive get restored, rather than losing them to a copy run under your own account.

The configuration file rewards the same kind of reading. It is twenty-two lines long ^[10]. Six of them pin the Cortex-A9 core, Linux 6.18.7, the vexpress kernel defconfig, the `arm/vexpress-v2p-ca9` device tree and a 64 MB ext2 root filesystem ^[11]. That leaves sixteen ^[13], which the walkthrough disposes of in one sentence about a patch directory, DHCP on `eth0`, a post-image script and a host QEMU build, with the instruction to work out what each line does before moving on ^[12]. The instruction is the useful part. Sixteen unread lines is how a target definition acquires behaviour nobody on the team can account for.

Two practical notes on the build itself. The cross toolchain is compiled from source before any target package, and only later builds reuse it ^[16]. And when it comes time to boot the result, the board directory ships a readme with the exact QEMU command line ^[21], which is the same lesson in miniature: the tree already contains the answer, and guessing at emulator options produces bugs that present as image bugs.

One line is worth grepping for in anyone's flashing script or CI job, which is the directory it reads from. `output/images` is a short, checksummable list of artefacts: kernel image, device tree blob, bootloader, root filesystem images ^[4]. `output/target` will pass a file-by-file comparison against a working system and still fail on the bench ^[3].