4-Day Training Agenda: Linux + Yocto Embedded Linux (Basic → Advanced)

Release baseline used in this course: current stable Yocto 5.3 (Whinlatter, Dec 2026) plus 5.0 (Scarthgap LTS) practices for long-lived products. (wiki.yoctoproject.org)

Target audience

Embedded / platform / DevOps engineers who need to build, customize, secure, and operate an embedded Linux distro using Yocto.

Prerequisites (what participants should have)

• Comfortable with basic terminal usage (or we cover from scratch on Day-1)
• A Linux build machine (native or VM). For modern Yocto builds, expect ~32 GB RAM and ~140 GB free disk as practical minimums for a full image build. (docs.yoctoproject.org)
• Optional hardware board (any common ARM64/ARMv7 dev board). If not available, we use QEMU.

Day 1 — Foundations: Linux essentials + Yocto mental model + first boot

1) Linux fundamentals for embedded work

• Linux filesystem & hierarchy (rootfs layout, /proc, /sys, /dev)
• Users, groups, permissions, capabilities (what matters on devices)
• Processes, signals, jobs, scheduling basics (top, ps, nice, cgroups concepts)
• Services & boot basics (systemd overview, journald logs, units)
• Networking essentials (interfaces, routes, DNS basics, SSH hygiene)
• Core troubleshooting muscle: logs, dmesg, journald, strace/ltrace concepts

2) Embedded Linux landscape (where Yocto fits)

• Buildroot vs Yocto (trade-offs: customization depth, maintenance, scaling)
• Cross-compiling fundamentals (sysroot, toolchain, ABI, target triples)

3) Yocto architecture (the “why it works” model)

• Poky, OE-Core, BitBake, metadata layers, recipes
• Tasks, dependency graph, sstate cache concept (what rebuilds and why)
• Machines, distros, images: what each one controls

4) Hands-on deliverables (end of Day-1)

• Build environment setup (modern workflows)
• Create a build directory, set MACHINE, build a minimal image
• Boot the image in QEMU and validate: login, networking, services, logs

Day-1 output: “Hello Yocto” image booted (QEMU), plus a clear map of how layers/recipes/tasks connect.

Day 2 — Working like a Yocto engineer: BitBake, metadata, debugging, and build performance

1) BitBake deep dive (practical, not theoretical)

• Tasks and execution flow (fetch → unpack → patch → configure → compile → install → package → image)
• Variables & overrides (how configuration actually resolves)
• Common workspace files: local.conf, bblayers.conf, distro/machine config

2) Recipes, packages, and images

• Anatomy of a recipe (SRC_URI, patches, do_install, FILES, RDEPENDS)
• Packaging models (rpm/deb/ipk) and why you’d choose each
• IMAGE_FEATURES, packagegroups, recommended patterns for image composition

3) Debugging builds like a pro

• Where failures happen (fetch, patch, compile, QA, rootfs, image)
• Reading task logs, reproducing a task, inspecting WORKDIR
• Patch workflows (best practices for long-term maintainability)

4) Performance & scalability (modern best practices)

• Downloads and sstate strategy (local cache, shared cache, mirrors conceptually)
• Controlling parallelism and host resource usage (avoiding OOMs and thrashing)
• Hash equivalence & repeatable outputs (why teams use it at scale) (docs.yoctoproject.org)

Day-2 output: participants can confidently add packages/features, troubleshoot failures, and speed up rebuild cycles.

Day 3 — Productization & advanced customization: BSP, kernel, images, SDK, compliance

1) BSP and hardware enablement (board bring-up path)

• BSP layer design (what goes into meta-bsp vs meta-product)
• MACHINE tuning: CPU features, device selection, boot args, storage
• Kernel integration options:
  • Kernel recipe strategy (vendor vs mainline approach)
  • Device tree workflow and patch management
  • Kernel configuration fragments workflow (portable + maintainable) (docs.yoctoproject.org)
• Bootloader overview (U-Boot/EFI/GRUB concepts; where Yocto config lives)

2) Image engineering (real device concerns)

• Rootfs sizing, partitions, and WIC image creation
• Filesystem choices (ext4, squashfs, erofs, compressed images) and when to use which
• Advanced WIC patterns (extra partitions, artifact injection, reproducible layouts) (docs.yoctoproject.org)

3) Developer workflow for applications

• SDK vs eSDK vs “build inside Yocto” decision points
• devtool workflow (modify, build, deploy, finish) and team collaboration model
• Exporting toolchains/SDKs and integrating with IDE/CI pipelines

4) Security, SBOM, and release governance (what’s now expected)

• License compliance workflow (SPDX concepts, manifests, audits)
• SBOM generation and consumption strategy (build-time artifacts and pipelines) (docs.yoctoproject.org)
• Vulnerability workflows: CVE scanning, triage, suppressions/justifications, and release gating
• QA checks and “quality gates” approach for product builds (docs.yoctoproject.org)

Day-3 output: a custom layer (meta-yourproduct), a bootable image with your selected packages/services, WIC-based image artifacts, and an SDK/eSDK workflow.

Day 4 — Using the created Linux: operating, debugging, updating, and maintaining Yocto-built systems (full day)

This day is dedicated to running and using the Linux you built with Yocto—exactly as requested.

1) Boot, flash, and verify on target (or QEMU if no hardware)

• Boot flow: bootloader → kernel → init/systemd → services
• Flashing methods by artifact type (wic image, sdcard image, raw partitions)
• First-boot checklist: clocks/time, networking, storage mounts, logs, CPU/mem sanity

2) Day-to-day embedded Linux operations (hands-on)

• User access, SSH hardening basics, key management
• Service management with systemd (enable/disable, override files, targets)
• Logging & troubleshooting: journalctl patterns, persistent logs, crash collection
• Networking in the field: DHCP vs static, DNS troubleshooting, firewall basics
• Storage reliability basics: fs checks, wear/partition strategies (conceptual)

3) Deploying and debugging your application on Yocto Linux

• Using the SDK to build an app, deploy to target, validate runtime deps
• Debugging: gdb/gdbserver basics, core dumps, strace on real issues
• Performance checks: boot time, memory footprint, CPU usage, IO bottlenecks

4) Updating and maintaining devices (practical strategy)

• Package feeds vs image-based updates (trade-offs and recommended usage)
• Update safety principles: A/B concepts, rollback thinking, power-loss tolerance
• How Yocto artifacts and versioning support long-term maintenance (release discipline)
• Using run-time images efficiently (including modern run tooling improvements) (docs.yoctoproject.org)

Day-4 output: a working “field-ready” operational playbook: boot + verify + manage services + debug + update strategy for a Yocto-built device.

Capstone deliverables (end of 4 days)

• A reproducible Yocto workspace layout (team-friendly)
• Custom meta layer (product layer) and one bootable image (QEMU + optional hardware)
• WIC image artifacts + SDK workflow
• Basic SBOM + vulnerability reporting flow integrated into the build pipeline (docs.yoctoproject.org)
• Operations checklist for using and supporting the deployed Linux in real environments

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.