EMB-301 · Embedded Linux & BSP
Read-Only Rootfs & OTA Updates
Update strategies that survive power loss in the field, and the filesystem layout that makes them possible.
Who this course is for
Product engineers shipping connected embedded devices, who need field updates that survive power cuts, bad networks and their own mistakes — without a truck roll.
Prerequisites
Course outline
Day 1 — The filesystem layout that makes updates possible
- Why a writable rootfs is an update liability
- Read-only rootfs with an overlay for mutable state: /etc, /var and the factory-reset question
- Partition design: system, state and recovery roles
- What belongs in the read-only set and what never does
- Testing that the system genuinely tolerates read-only operation
Day 2 — Atomic updates and the updaters
- A/B partition schemes and the bootloader cooperation they need
- Atomic switching: bootcount, boot targets and the upgrade flag
- RAUC, SWUpdate and Mender compared: architecture, signing, integration cost
- Integrating an updater into Yocto and Buildroot
- Update artifacts: formats, signing and delivery
Day 3 — Failure handling and constrained fleets
- Rollback and health checks: what proves a boot was good
- Power-loss mid-update: what each updater guarantees and what it does not
- Delta updates and bandwidth-constrained deployments
- Update testing: staged rollouts, canaries and fleet telemetry
- The update runbook: what operations does when it goes wrong
Hands-on labs
Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach
- Lab: Convert an image to a read-only rootfs with a state overlay, and prove with tests that it survives a power cut
- Lab: Integrate RAUC (or SWUpdate) into a build and perform a full A/B update on the lab board
- Lab: Cut power mid-update and document exactly what the system did on the next boot
- Lab: Implement a health check with rollback: boot a deliberately broken update and watch the system return to the good slot
- Lab: Generate a delta update and measure the bandwidth saving against a full image on a constrained link
Capstone project
Deliver an update-capable product image on the lab board: read-only rootfs with state separation, A/B updates with bootloader cooperation, signed artifacts, a health-check-driven rollback and a delta-update path — validated by a scripted failure gauntlet (power cut, corrupt artifact, broken update) whose recovery logs form the evidence pack.
What you leave with
- A read-only rootfs design with sane state management
- A working A/B update path integrated into your build system
- Measured knowledge of what your updater does on power loss
- Rollback and health-check patterns tested against real failure
- A fleet update runbook starting from evidence, not hope
How it runs
Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.
Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.
Questions
Who is this course for?
Product engineers shipping connected embedded devices, who need field updates that survive power cuts, bad networks and their own mistakes — without a truck roll. It sits at practitioner level within the Embedded Linux & BSP track.
What do I need to know already?
Specific prerequisites for this course: Embedded Linux fundamentals: partitions, filesystems, boot flow; A build system (Yocto or Buildroot) at user level; U-Boot environment concepts helpful. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.
Can this run privately for my team?
Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.
What is the difference between in-person and online?
In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.
Do you invoice companies?
Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.
Upcoming dates
| Dates | Where | Seats | Early bird | Regular | |
|---|---|---|---|---|---|
| 8 Nov – 10 Nov 20263 full days | RiyadhIn person · KAFD Conference Centre | 4 of 14 | SAR 7,090until 9 Oct | ||
| 15 Nov – 17 Nov 20263 full days | Kuwait CityIn person · Al Hamra Tower | 9 of 14 | KWD 580until 16 Oct | ||
| 15 Nov – 17 Nov 20263 full days | MuscatIn person · Knowledge Oasis Muscat | 4 of 14 | OMR 730until 16 Oct | ||
| 22 Nov – 29 Nov 20266 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 4 of 20 | US$1,350until 23 Oct | ||
| 23 Nov – 25 Nov 20263 full days | OttawaIn person · Kanata North Tech Park | 9 of 14 | CAD 2,570until 24 Oct | ||
| 30 Nov – 2 Dec 20263 full days | TorontoIn person · MaRS Discovery District | 4 of 14 | CAD 2,570until 31 Oct | ||
| 30 Nov – 2 Dec 20263 full days | LondonIn person · Shoreditch Works | 9 of 14 | GBP 1,480until 31 Oct | ||
| 30 Nov – 7 Dec 20266 half-days | Europe bandLive online · 09:00–13:00 CET | 9 of 20 | US$1,350until 31 Oct | ||
| 30 Nov – 7 Dec 20266 half-days | Americas bandLive online · 13:00–17:00 ET | 14 of 20 | US$1,350until 31 Oct | ||
| 7 Dec – 9 Dec 20263 full days | BerlinIn person · Factory Görlitzer Park | 4 of 14 | EUR 1,740until 7 Nov |
Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.
More in Embedded Linux & BSP
EMB-1014 days
Yocto Project Fundamentals
BitBake, layers and recipes, from a first build to an image you would actually ship.
Practitioner-taught
SAR 10,500Next 15 Nov
EMB-1104 days
Custom BSP Layers
Writing a board support layer from scratch: machine configuration, kernel recipe, bootloader and device tree.
Practitioner-taught
SAR 12,000Next 25 Oct
EMB-1203 days
Buildroot in Practice
The lighter alternative to Yocto: when Buildroot is the right call and how to use it well.
Practitioner-taught
SAR 7,880Next 11 Oct
EMB-2013 days
U-Boot Porting & Customisation
The bootloader layer: board bring-up, environment, boot scripts and recovery paths.
Practitioner-taught
SAR 9,000Next 18 Oct
EMB-2103 days
Secure Boot & Chain of Trust
Establishing and maintaining a verified boot chain from ROM to userspace, including key management reality.
Practitioner-taught
SAR 9,000Next 15 Nov
EMB-2202 days
Init Systems & Fast Boot
systemd and the alternatives, plus measuring and cutting boot time to a target.
Practitioner-taught
SAR 5,250Next 1 Nov
EMB-3102 days
SBOM & Licence Compliance
Producing a defensible software bill of materials and meeting open source licence obligations — now a regulatory matter, not just good practice.
Practitioner-taught
SAR 5,250Next 25 Oct
EMB-3202 days
Long-Term Maintenance Strategy
Keeping a shipped product secure and buildable for a decade, which is where most embedded programmes fail.
Practitioner-taught
SAR 6,000Next 22 Nov