For a fixed-function product built in volume on one board, build the image with Yocto, because it gives control over every package, build option and licence in the image. Choose a Debian-based image when the application needs many packages that Debian already provides and the team knows Debian. Choose Ubuntu Core when the team wants a vendor-supported, transactional base and accepts a dependence on Canonical. The main trade-off is control against effort and vendor dependence.
Before an embedded Linux project writes any application code, it must decide what produces the root filesystem. The choice between Debian vs Yocto, with Ubuntu Core as a third candidate, sets how the team builds, patches, updates and audits the product for its whole life. Yocto vs Buildroot compares two build systems that compile everything from source. This article compares a source-built image with two images assembled from distribution binary packages.
The context
The decision arises when a team moves from a vendor evaluation image to its own product image. That image is often Debian, Ubuntu or a Yocto build supplied by the SoC vendor, and it works on the development board. The team must decide whether the product continues in the same style or is rebuilt on a different base.
Five forces matter. The first is the length of the product’s field life, which sets how long security fixes must keep arriving. The second is the number of existing software packages the application depends on. The third is the unit volume, because a larger volume justifies more upfront work on image size and cost. The fourth is the skill the team already has. The fifth is the evidence the product must produce for customers or regulators, such as a software bill of materials.
The options
Option 1: Yocto, built from source
The Yocto Project builds every package from recipes, so the image contains only what the team selects, compiled with the options the team chooses. Releases follow a six-month cadence, in April and October. A stable release is supported for seven months. A Long Term Support (LTS) release is made every two years and is supported for four years. The Yocto wiki lists Scarthgap 5.0 (April 2024, end of life April 2028) and Wrynose 6.0 (April 2026, end of life April 2030) as the current LTS releases.
- Advantages: full control over package set, build flags and licences; an SPDX software bill of materials is produced by the
create-spdxclass, which is inherited by default and writes anIMAGE-MACHINE.spdx.jsonfile for each image; vendor BSPs are commonly published as Yocto layers. - Disadvantages: a steep learning curve and long first builds; the team owns the layer stack and must move it to a new LTS release; the LTS commitment applies to the release itself, so each additional layer needs its own maintenance plan (see what the Yocto LTS covers, and what it does not).
Option 2: a Debian-based image
A Debian-based image starts from binary packages in a Debian archive. Isar, developed by ilbers GmbH and Siemens AG, is a set of scripts that generate Debian-based root filesystems and uses BitBake as the task engine. It takes the base system from Debian binary repositories and builds the team’s own packages with sbuild. debos reads a YAML recipe of actions such as debootstrap, apt and image-partition, and runs them inside a virtual machine created by fakemachine. ELBE, from Linutronix, is another build environment in this group.
Debian 13 (trixie) was released on 9 August 2025. Its release page lists end of life on 9 August 2028, end of LTS on 30 June 2030 and end of Extended LTS on 30 June 2035. Debian LTS is handled by a separate group of volunteers and companies, not by the Debian security team. The Civil Infrastructure Platform builds its CIP Core reference images from Debian LTS source packages, using Isar or Poky with meta-debian.
- Advantages: the application installs tested packages with
aptinstead of writing recipes; a long published security schedule for packages in the archive; no commercial agreement is needed. - Disadvantages: packages are built for a generic architecture, not one SoC; the package set is fixed by Debian and the image is usually larger; the board still needs its own bootloader and kernel.
Option 3: Ubuntu Core
Canonical describes Ubuntu Core as an immutable and transaction-based version of Ubuntu for cloud, embedded and IoT systems, with automatic rollback. Canonical states that the kernel, the base operating system and the applications are all delivered as snaps, and that the team declares which snaps go into the image instead of building the system from source. Classic Ubuntu, which uses apt like Debian, is a separate product. Ubuntu LTS releases receive five years of standard security maintenance. Expanded Security Maintenance through an Ubuntu Pro subscription extends this by five years, and a Legacy add-on extends it further. For Ubuntu 26.04 LTS (April 2026), Canonical lists standard maintenance to May 2031, ESM to May 2036 and the Legacy add-on to May 2041. Canonical’s own comparison page also claims up to 15 years of support for Ubuntu Core with Ubuntu Pro.
- Advantages: a commercial vendor maintains the kernel and base; transactional updates with rollback are part of the platform instead of a separate project; the longest published support period of the three.
- Disadvantages: the long period requires a paid subscription; the product depends on Canonical’s snap tooling, update service and terms; applications must be packaged as snaps; the claims about Ubuntu Core in this article come from Canonical’s own pages, which give no measured size or boot-time figures.
The decision: Debian vs Yocto vs Ubuntu Core
For the common case, a fixed-function device built in volume on one board with a small, known set of applications, use Yocto. The team can limit the image to the required packages, keep it small, and produce a software bill of materials from the build. A customer or regulator asks for these properties first, and they are weakest in a general-purpose package archive.
Use a Debian-based image when the application depends on many existing packages, the team has Debian experience and no Yocto experience, or the volume is low enough that development time matters more than image size. A recipe-driven Debian image built with Isar or debos is a legitimate product architecture, and CIP Core shows that the approach is used for industrial platforms.
Use Ubuntu Core when the team prefers to buy maintenance instead of building it, needs transactional updates without assembling a separate update stack, and accepts Canonical as a supplier for the life of the product. This is a reasonable choice for a small team with a long support requirement and a budget for subscriptions.
No source read for this article gives measured image size or boot time for all three options on one board, so measure your own board with your own application before the decision is final.
Consequences
Choosing Yocto means the team owns the layer stack. It must keep layers aligned to one release, move to the next LTS release before the current one ends, and track fixes for every recipe in the image. In return, the image content is known exactly.
Choosing Debian means fixes arrive through the archive, but only for packages as Debian builds them. Any package the team compiles itself, and the kernel and bootloader for the board, remain the team’s responsibility. The team must also choose and build its own update mechanism.
Choosing Ubuntu Core moves update and base maintenance to the vendor, and moves part of the product’s future to the vendor as well: pricing, tooling changes and support terms are outside the team’s control. Moving between bases later changes the build, the update payload and the test baseline together, so the choice is better made before the first customer release. All three options still need a defined recovery path for a failed update.
These trade-offs are practised in the build-system modules of the TECH VEDA Embedded Linux and Yocto programme.
Key takeaways
- In the Debian vs Yocto choice, the images differ mainly in who controls the package build: the product team or the Debian project. Ubuntu Core moves that control, and the update mechanism, to Canonical.
- Default to Yocto for a fixed-function device in volume; choose Debian for package breadth or team skill, and Ubuntu Core for vendor-supported transactional updates.
- A Yocto LTS release is supported for four years; Debian lists end of LTS about five years after release; Ubuntu LTS has five years of standard maintenance, with longer coverage on a paid subscription.
- No base removes the need to own the board’s kernel, bootloader choice and recovery path.
- Measure image size, boot time and memory on your own board before committing.
Frequently asked questions
Can a Debian-based image be reproducible like a Yocto build?
A recipe-driven tool makes the assembly repeatable. Isar generates the root filesystem from a selected apt repository and builds custom packages with sbuild, and debos runs its recipe actions inside a virtual machine created by fakemachine. The content still depends on the state of the Debian archive that the build reads.
How long does each option receive security updates?
A Yocto LTS release is supported for four years. Debian 13 is listed with end of LTS on 30 June 2030 and end of Extended LTS on 30 June 2035. Ubuntu 26.04 LTS has standard maintenance to May 2031, and ESM through Ubuntu Pro to May 2036. These dates cover the distribution or release, not the product’s own packages.
Does choosing Debian or Ubuntu remove the need for a vendor BSP?
Not for a board without existing support. These images supply user-space packages or, for Ubuntu Core, a snap-based platform. For a board that no distribution supports, the bootloader, kernel and device tree still have to come from the vendor, from mainline Linux or from the team.
Which option produces a software bill of materials?
Yocto produces an SPDX file for each image through the create-spdx class, which is inherited by default. For the other options, the format and the completeness for the team’s own packages depend on the tools that the team adds.
