OSS + ELC EU 2026

Linux userspace is built on a long history of trusted pieces c, libc, shell scripts, BusyBox, coreutils, PAM, NSS, and many assumptions that most systems inherit by default. These pieces work, and they have solved real problems for decades. But they also carry complexity from a different time.

We explore a userspace with fewer moving parts, no traditional libc dependency, simple deployment, easy cross-compilation, readable system code, and fewer external runtime dependencies. The goal is not to replace everything just for the sake of being different. The goal is to understand what still needs to exist, what can be simplified, and what becomes harder when we stop relying on the usual stack.

By rebuilding familiar userspace components from the ground up, we learn which old assumptions are still valuable, which ones are accidental complexity, and where embedded or minimal Linux systems can become simpler without becoming fragile.

This is a practical report from trying to redesign Linux userspace instead of only replacing individual tools. It covers what worked, what broke, and what the experiment teaches us about building smaller, simpler, and more maintainable Linux systems today.

In a system with "secure boot", you want to lock down most aspects of the system, in particular the bootloader.

On the other hand, implementing A/B updates requires to keep a writable bootloader environment to implement several aspects of A/B updates: adapting the kernel command line to the active partition, counting boot attempts and implementing recovery after deploying a defective update. Without a careful implementation, this could open the door to altering the sequence of boot commands or to introducing unwanted kernel parameters, therefore breaking the security of the bootloader and the rest of the system.

Both secure boot and A/B updates techniques are well documented, but most often without considering their mutual requirements. In this presentation, I will share solutions I found and used in a recent project. I will also share implementation details with U-Boot and the Yocto Project.

Designing immutable filesystems is becoming the default for embedded Linux development: they're more secure, easier to reason about, and resilient to field drift. But they make a once-easy thing surprisingly awkward: a one-line fix to a single script means shipping a whole new rootfs and rebooting the device.
systemd-sysext addresses half this problem by merging extension images onto /usr/ at runtime, with integrity enforced via dm-verity. But sysext is the activation mechanism only — it says nothing about how those signed images reach a fleet of devices in the first place.
This talk walks through a working proof-of-concept that closes the gap: a verity-signed sysext image, delivered over the air through a standard OTA framework, merged live onto a read-only Ubuntu rootfs, with health checks and automatic rollback on failure — all without a single reboot.
This talk covers the architecture end to end, the non-obvious operational gotchas, and an honest accounting of what this approach does and doesn't replace.

The last decade has shown a clear trend in dramatically increasing the boot process of modern SoC. If the i.MX6 bootflow reads like a short novel, the i.MX95 or TI K3 bootflow is a whole encyclopedia.

Today's heterogeneous SoCs combine CPUs of different types — Cortex-R/M cores alongside the application-class Cortex-A — and boot now begins on one of the smaller cores before handing control over to the Cortex-A. There are good reasons for this, such as meeting functional-safety requirements, but it is also a real burden for system designers who simply want to run Linux on the Cortex-A cores and make use of the GPU or VPU.

Each new component needs its own firmware: ideally built from open source, though closed-source pieces remain in the chain. The result is no shortage of cryptic acronyms — TF-A, FF-A, TEE, SCMI, PSCI, SCP, FIP.

This talk sheds some light into the dark. It explains what each of these components actually does and how they fit together. Attendees will leave able to map this general picture onto their own SoC, see which parts are open source and which are not, and know where to look when the bootflow misbehaves.

While bootc has been gaining a lot of momentum over the last few years, we had been using a similar technology in production for over a decade. This timeline has given us long enough to go through the whole life-cycle of thousands of devices: initial provisioning, operating, delivering updates, and decommissioning.

Though our system is based on Yocto and Moby and specifically tailored for over 100 different (mostly edge/embedded) device types, it shares the same core principle of modern bootable container architecture: shipping the OS as a container image and configuring the init system to boot directly into it.

During the session, you will learn:
* How to boot into a containerized rootfs.
* How to manage state, persistent data, and OS updates via container registries over unstable networks.
* Lessons learned from 10 years of using bootable containers on 100+ different edge hardware types.

Prerequisites: Attendees should have a general understanding of OCI containers, Dockerfiles, and container registries.

Traditionally, embedded systems were simple enough that an initramfs was not needed at all. This has changed in the last recent years with new requirements, often related to verified boot. That means that additional steps are now needed before the rootfs can be mounted.

Existing solutions, such as the Yocto initramfs-framework have significant drawbacks. The resulting initramfs is quite big (multiple megabytes) which has a noticeable impact on the boot time. And while the shell scripts make it easy to customize, robust error handling is difficult.

In this talk, Michael will introduce rsinit (https://github.com/pengutronix/rsinit), a single-binary-initramfs for embedded systems, written entirely in Rust.
It is tiny (less than 200 KiB), very fast and "just works" for simple use-cases. Alternatively, it can be uses as a library crate to build a fully custom binary.

Beyond being small, it brings the full power of Rust to the initramfs, which allows building additional features (such as splash screens or read-ahead) without pulling in further dependencies.

Michael will present the existing features, explain the design choices and give an overview of what is planed for the future.

Android Auto requires Google's device integrity checks before it will connect to a car head unit, which by design locks the protocol to stock Android. Mainline mobile Linux phones have no path to car integration as a result.

LibreCar is an open-source implementation of the Android Auto protocol for the phone side. It lets any mainline Linux phone connect to a head unit wirelessly over Bluetooth and Wi-Fi, or wired over USB, without depending on Android or Google.
.
This talk walks through what it takes to open a session with a head unit, how to compose and stream the video output it expects, and how to read touch input back from the interface.

Containers ship everywhere, yet their software supply chain remains murky. Today's SBOM tools work backwards, scanning a finished image to guess what's inside — an approach prone to omissions and inaccuracies that the EU Cyber Resilience Act will make increasingly untenable.

The Yocto Project uses a fundamentally different path. Because we build everything from source, we generate an accurate, complete SPDX 3.0 SBOM during the build, not after it — with full license and provenance information. In this presentation, we discuss a new approach that lets us build minimal, multi-layer OCI container images using standard Yocto tooling, with no special privileges required, to produce repeatable and auditable results.

We will demonstrate end-to-end automation on the Yocto Project AutoBuilder: building reference container images, attaching SBOM and license attestations, signing them, and pushing to public registries. Attendees will leave understanding how reproducible builds, from source, close the container manifest gap — and how to consume these images today.

Since the introduction of the first Samsung DSI panel, the Linux DRM panel API became an important piece of software used to enable displays across very different hardware architectures. However, the panel support API hasn't evolved much since then.

Currently, the API is showing its age alongside modern graphics stacks. It doesn't support the atomic DRM API and lacks the ability to adapt the power setup while changing DRM modes. Furthermore, it doesn't support the advanced features that new Display Driver ICs (DDIC) heavily rely on, such as standby and advanced power states, advanced color management, dynamic rate switching, command mode self-refresh and more.

Neil will present you the history of the panel API from its origins, outline its current architectural limitations, and lead this BoF to discuss how to bring Linux DRM Display Panel support into the modern age. This open discussion will focus on how to collaboratively solve all those missing features to support modern devices and close the widening gap with downstream vendor support.