in conf/
to set up the shell
Typical build disk usage
What You Will Learn
Prerequisites
A 64-bit Linux host (Ubuntu 22.04 or newer is well tested), roughly 50-100 GB of free disk space, git, and the Yocto host build-essential package set. If you followed our earlier Buildroot lectures in this free embedded systems course, your host machine is very likely already ready to go.
Step 1: Install Host Packages
Every Yocto release documents an exact list of required host packages in its reference manual, and it does change slightly between releases, so always check the manual for the branch you are building. On a Debian/Ubuntu host, a typical starting set looks like this:
$ sudo apt update
$ sudo apt install -y gawk wget git diffstat unzip texinfo gcc build-essential
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils
iputils-ping python3-git python3-jinja2 libegl1-mesa liberror-perl
python3-subunit zstd liblz4-tool file locales
$ sudo locale-gen en_US.UTF-8
Step 2: Clone Poky on the Current LTS Branch
Rather than cloning the default branch, always clone the codename of the release you want. At the time of writing, the current LTS release is 6.0 “Wrynose”, with 5.0 “Scarthgap” still under support as the previous LTS. Pick whichever your product’s support window calls for:
$ git clone -b wrynose git://git.yoctoproject.org/poky.git
$ cd poky
You will find everything — oe-core, BitBake, and the reference Poky configuration —
inside this single poky directory.
Step 3: Set Up the Build Environment
Every new terminal session needs the environment script sourced before any
bitbake command will work:
$ source oe-init-build-env
This creates and switches into a working directory named build, and drops
you into it as your current directory. You can also name the directory explicitly, which
is useful for keeping several targets side by side:
$ source oe-init-build-env build-ep-qemuarm64
Step 4: Configure the Target Machine
Open conf/local.conf in your build directory and set the MACHINE
variable to a QEMU target. For a 64-bit ARM target:
$ sed -i 's/^MACHINE ??= "qemux86-64"/MACHINE ??= "qemuarm64"/' conf/local.conf
$ grep '^MACHINE' conf/local.conf
MACHINE ??= "qemuarm64"
It’s also worth pointing the shared caches outside your build directory the first time, so every future build directory you create reuses already-built artifacts instead of rebuilding from scratch:
DL_DIR ?= "/home/ravi/yocto-shared/downloads"
SSTATE_DIR ?= "/home/ravi/yocto-shared/sstate-cache"
Step 5: Build and Boot an Image
With the machine configured, build a minimal image. Expect the very first build to take anywhere from thirty minutes to a few hours depending on your hardware and network, since it compiles the entire toolchain and root filesystem from source:
$ bitbake core-image-minimal
Typical tail of a successful build looks like this:
NOTE: Tasks Summary: Attempted 3842 tasks of which 0 didn't need to be rerun
and all succeeded.
Summary: There was 1 WARNING message.
Boot the resulting image straight in QEMU:
$ runqemu qemuarm64 nographic
Poky (Yocto Project Reference Distro) 6.0 ep-qemuarm64 ttyAMA0
ep-qemuarm64 login: root
Common Mistakes
Cloning the default branch instead of a named release
Cloning without -b <codename> gives you an unstable
development branch, not a supported release — always pin the branch explicitly.
Opening a new terminal and forgetting to re-source
bitbake: command not found almost always means
oe-init-build-env was not sourced in that particular shell session.
Running out of disk space mid-build
A full build of even a minimal image easily needs 40-50 GB; check available space before starting a long build rather than after it fails hours in.
Best Practices
Summary and Key Takeaways
Installing Yocto Project is really just cloning Poky on the correct release
branch and sourcing oe-init-build-env to generate a build directory.
The three configuration files inside conf/ — local.conf, bblayers.conf
and templateconf.cfg — control almost everything about what gets built and how. Once
MACHINE is set, a single bitbake command turns those
recipes into a bootable image you can run instantly under QEMU, no real hardware
required.
Frequently Asked Questions
Do I need to source oe-init-build-env every time?
Yes, in every new terminal session before running any bitbake command; it sets required environment variables and switches you into the build directory.
How much disk space does a Yocto build actually need?
Plan for 40-100 GB depending on the image and how many layers you add; the shared download and sstate caches also grow over time across multiple projects.
Can I build for real hardware instead of QEMU?
Yes — set MACHINE to the value defined by your board’s BSP meta-layer instead of a qemu target, after adding that layer to bblayers.conf.
Why does the first build take so long?
The first build compiles an entire cross-toolchain and root filesystem from source; later builds reuse the sstate cache and are dramatically faster.
What’s the difference between local.conf and bblayers.conf?
local.conf configures the machine, distro and build behavior; bblayers.conf lists which meta-layers are active for this particular build directory.
Is it safe to delete the tmp directory?
Yes, tmp/ is fully regenerated by BitBake on the next build; nothing you hand-authored should ever live there.
Continue This Free Linux Kernel Development Course
Next up: adding your own meta-layer and writing a custom recipe.

2 Comments