Apertis v2021dev1 Release
Apertis is a Debian derivative distribution geared towards the creation of product-specific images for ARM (both the 32bit ARMv7 and 64-bit ARMv8 versions using the hardfloat ABI) and Intel x86-64 (64-bit) systems.
Apertis v2021dev1 is the second development release of the Apertis v2021 stable release flow that will lead to the LTS Apertis v2021.0 release in March 2021.
This Apertis release is built on top of Debian Buster with several customisations.
Test results for the v2021dev1 release are available in the following test reports:
- 2019 Q4: v2021dev0
- 2020 Q1: v2021dev1
- 2020 Q2: v2021dev2
- 2020 Q3: v2021dev3
- 2020 Q4: v2021pre
- 2021 Q1: v2021.0
- 2021 Q2: v2021.1
- 2021 Q3: v2021.2
- 2021 Q4: v2021.3
- 2022 Q1: v2021.4
- 2022 Q2: v2021.5
- 2022 Q3: v2021.6
- 2022 Q4: v2021.7
|Apertis v2021dev1 images
|ARM 32-bit (U-Boot)
|ARM 64-bit (U-Boot)
Apertis v2021dev1 repositories
deb https://repositories.apertis.org/apertis/ v2021dev1 target development sdk hmi
Secure boot on i.MX6 SABRE Lite technology preview
A first iteration of trusted boot on the i.MX6 SABRE Lite boards is now part of the minimal and target ARM 32-bit OSTree images.
Based on the High Assurance Boot v4 (HABv4) functionality embedded in the the boot ROM, the current implementation verifies the trust chain of the bootloader, the kernel, the dtb and the initramfs. At the moment no checks are done after that to validate the root filesystem and its contents, including kernel modules loaded on-demand.
u-boot shipped in the
and the FIT images containing the kernel, dtb and initramfs on the minimal and
armhf images are all signed with the Apertis development
Touch input on the reference i.MX6 SABRE Lite setup
The v2021dev1 release ships the latest 5.4.13 kernel and enables the Egalax driver to be able to handle input from the reference LVDS touchscreen for the i.MX6 SABRE Lite boards when using the HMI on the target images.
Build and integration
Docker image generation on GitLab CI
The Apertis Docker images are now being produced from GitLab CI pipelines rather than from Jenkins.
The more integrated solution offered by GitLab provides better access controls, easier maintenance of the published images, and the ability to run the pipeline on development branches and merge request, before hitting the main branches.
GitLabCI-based image building pipeline technology preview
This release marks the beginning of the conversion of the big Jenkins-based image build pipeline to GitLab CI with the goals of converging to a single, easy to use Continuous Integration solution and to be able to transparently use autoscaled cloud workers instead of dedicated machines.
The implementation is based on a set of YAML templates for the image building pipeline itself combined with a new backend for Debos/Fakemachine based on User Mode Linux to get the needed performance even on cloud workers where KVM-based nested virtualization is not available.
The official switch of the main pipeline is expected to happen during the v2021dev2 release cycle.
Flatpak runtime and application build pipeline technology preview
The GitLab CI infrastructure has been the basis for the first iteration of the pipeline building a Flatpak runtime and Flatpak application based on Apertis.
As described in the Application Framework document, Apertis plans to adopt Flatpak as the reference application deployment mechanism.
www.apertis.org website refresh
The main Apertis website www.apertis.org got converted from Mediawiki to a static website usng the Hugo rendering engine and GitLab CI pipelines.
Being a static website, www.apertis.org is now much faster and more secure than before.
A visual refresh has been also part of the transition, making the website more modern and pleasant. Some contents have also been reorganized and revamped, in an ongoing effort to keep them up to date and to make them easier to navigate.
Long term reproducibility
A new document addresses the need to reproduce builds in the long term, helping product teams during the whole lifecycle of their products.
Deprecations and ABI/API breaks
During this release cycle we have continued to mark obsolete or problematic APIs with the ABI break tag as a way to clear technical debt in future.
FIT support is mandatory for the ARM 32-bit OSTree images
The secure boot implementation of the i.MX6 SABRE Lite boards requires the kernel, initramfs, and DTB to be packed in a FIT image.
Unfortunately versions of
u-boot prior to 2018.11+dfsg-2co2 as shipped by
Apertis lack the support for FIT images, so they are unable to boot the
new v2021dev1 ARM 32-bit images.
To update the copy of
u-boot on the SPI onboard flash memory of your i.MX6
SABRE Lite board with a version which is able to boot the new images it is
sufficient to boot the
on the device.
Docker images are now hosted on the Apertis GitLab Docker registry
With the switch to GitLab CI for the generation of the Apertis Docker images
they are now published on the registry integrated in the Apertis GitLab
Images for older releases are still available on the
docker-registry.apertis.org registry, but newer releases will only
publish their Docker images at
Image references such as
docker-registry.apertis.org/apertis/apertis-v2021dev1-image-builder will need
to be updated to point at
Apertis Docker registry
The Apertis Docker registry stores Docker images in order to provide a unified and easily reproducible build environment for developers and services.
As of today, this includes the
Apertis infrastructure tools
The Apertis v2021 infrastructure
provides packages for the required versions of
ostree for Debian Buster:
deb https://repositories.apertis.org/infrastructure-v2021/ buster infrastructure
Image daily builds, as well as release builds can be found at:
Image build tools can be found in the Apertis tools repositories.
The Image build infrastructure document provides an overview of the image building process and the involved services.