Compare commits
1 Commits
HEAD
...
feat/add_r
| Author | SHA1 | Date |
|---|---|---|
Patrick Vogelaar
|
6434d45e04 |
|
|
@ -3,5 +3,4 @@ vscode-bitbake-build/
|
|||
documentation/_build/
|
||||
documentation/oe-logs
|
||||
documentation/oe-workdir
|
||||
__pycache__
|
||||
.venv/
|
||||
__pycache__
|
||||
|
|
@ -2,35 +2,23 @@
|
|||
path = bitbake
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/bitbake.git
|
||||
branch = 2.0
|
||||
[submodule "openembedded-core"]
|
||||
path = external-layers/openembedded-core
|
||||
[submodule "layers/openembedded-core"]
|
||||
path = layers/openembedded-core
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/openembedded-core.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-openembedded"]
|
||||
path = external-layers/meta-openembedded
|
||||
[submodule "layers/meta-openembedded"]
|
||||
path = layers/meta-openembedded
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-openembedded.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-virtualization"]
|
||||
path = external-layers/meta-virtualization
|
||||
[submodule "layers/meta-virtualization"]
|
||||
path = layers/meta-virtualization
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-virtualization.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-efibootguard"]
|
||||
path = external-layers/meta-efibootguard
|
||||
[submodule "layers/meta-efibootguard"]
|
||||
path = layers/meta-efibootguard
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-efibootguard.git
|
||||
branch = master
|
||||
[submodule "meta-swupdate"]
|
||||
path = external-layers/meta-swupdate
|
||||
branch = coreos/master
|
||||
[submodule "layers/meta-swupdate"]
|
||||
path = layers/meta-swupdate
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-swupdate.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-arm"]
|
||||
path = external-layers/meta-arm
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-arm.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-ti"]
|
||||
path = external-layers/meta-ti
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-ti.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-lts-kernel-mixin"]
|
||||
path = external-layers/meta-lts-kernel-mixin
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-lts-mixins.git
|
||||
branch = coreos/kirkstone/kernel
|
||||
|
|
|
|||
|
|
@ -1,10 +1,6 @@
|
|||
{
|
||||
"recommendations": [
|
||||
"ms-vscode.makefile-tools",
|
||||
"timonwong.shellcheck",
|
||||
"kweihmann.oelint-vscode",
|
||||
"lextudio.restructuredtext",
|
||||
"trond-snekvik.simple-rst",
|
||||
"yocto-project.yocto-bitbake"
|
||||
"timonwong.shellcheck"
|
||||
]
|
||||
}
|
||||
|
|
@ -1,47 +1,8 @@
|
|||
{
|
||||
"files.watcherExclude": {
|
||||
"**/build/**": true,
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"search.exclude": {
|
||||
"**/build/**": true,
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"C_Cpp.files.exclude": {
|
||||
"**/build": true,
|
||||
"**/_build": true,
|
||||
},
|
||||
"python.analysis.exclude": [
|
||||
"**/build/**",
|
||||
"**/_build/**",
|
||||
],
|
||||
"python.formatting.provider": "black",
|
||||
"editor.rulers": [80,100,120],
|
||||
"bitbake.pathToBuildFolder": "${workspaceFolder}/build",
|
||||
"bitbake.pathToEnvScript": "${workspaceFolder}/coreos-init-build-env",
|
||||
"bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
|
||||
"python.autoComplete.extraPaths": [
|
||||
"${workspaceFolder}/bitbake/lib",
|
||||
"${workspaceFolder}/meta/lib"
|
||||
],
|
||||
"python.analysis.extraPaths": [
|
||||
"${workspaceFolder}/bitbake/lib",
|
||||
"${workspaceFolder}/meta/lib"
|
||||
],
|
||||
"[python]": {
|
||||
"diffEditor.ignoreTrimWhitespace": false,
|
||||
"gitlens.codeLens.symbolScopes": [
|
||||
"!Module"
|
||||
],
|
||||
"editor.formatOnType": true,
|
||||
"editor.wordBasedSuggestions": "off",
|
||||
"files.trimTrailingWhitespace": false
|
||||
},
|
||||
"[shellscript]": {
|
||||
"files.eol": "\n",
|
||||
"files.trimTrailingWhitespace": false
|
||||
},
|
||||
"bitbake.sdkImage": "coreos-image-minimal",
|
||||
"bitbake.workingDirectory": "${workspaceFolder}",
|
||||
"task.saveBeforeRun": "always",
|
||||
"**/build/cache/**": true,
|
||||
"**/build/downloads/**": true,
|
||||
"**/build/sstate-cache/**": true,
|
||||
"**/build/tmp/**": true
|
||||
}
|
||||
}
|
||||
2
bitbake
2
bitbake
|
|
@ -1 +1 @@
|
|||
Subproject commit 40fd5f4eef7460ca67f32cfce8e229e67e1ff607
|
||||
Subproject commit ac576d6fad6bba0cfea931883f25264ea83747ca
|
||||
|
|
@ -26,7 +26,7 @@ COREOS_ROOT=$(readlink -f "${COREOS_ROOT}")
|
|||
# Set the path to bitbake, openembedded-core and the template directory
|
||||
# All theses values can be overriden by the caller of coreos-init-build-env
|
||||
BITBAKEDIR="${BITBAKEDIR:-${COREOS_ROOT}/bitbake}"
|
||||
OEROOT="${OEROOT:-${COREOS_ROOT}/external-layers/openembedded-core}"
|
||||
OEROOT="${OEROOT:-${COREOS_ROOT}/layers/openembedded-core}"
|
||||
TEMPLATECONF="${TEMPLATECONF:-${COREOS_ROOT}/templates}"
|
||||
|
||||
# Sanity checks
|
||||
|
|
@ -84,11 +84,6 @@ coreos_path_add "${COREOS_ROOT}/scripts"
|
|||
# Add support for ##COREOS_LAYERSDIR## inside of bblayer template
|
||||
coreos-bblayers-envsub COREOS_LAYERSDIR "${COREOS_ROOT}/layers"
|
||||
|
||||
# Add support for ##COREOS_EXTLAYERSDIR## inside of bblayer template
|
||||
coreos-bblayers-envsub COREOS_EXTLAYERSDIR "${COREOS_ROOT}/external-layers"
|
||||
|
||||
# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything
|
||||
# if the directory already exist so it's safe to call it everytime
|
||||
# stdout is redirected to reduce the amount of output but not stderr
|
||||
#
|
||||
#Note: if a final build is detected all the dev keys are deleted
|
||||
# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything it
|
||||
# the directory already exist, so it's safe to call it everytime
|
||||
coreos-keygen > /dev/null 2> /dev/null
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
{
|
||||
"recommendations": [
|
||||
"ms-vscode.makefile-tools",
|
||||
"lextudio.restructuredtext",
|
||||
"trond-snekvik.simple-rst"
|
||||
]
|
||||
}
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
{
|
||||
"files.watcherExclude": {
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"python.formatting.provider": "black",
|
||||
"editor.rulers": [
|
||||
80,
|
||||
100,
|
||||
120
|
||||
],
|
||||
"esbonio.sphinx.confDir": ""
|
||||
}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
|
||||
/* Make tables more convenient by wrapping line instead of using an
|
||||
horizontal scrollbar */
|
||||
.wy-table-responsive table td, .wy-table-responsive table th {
|
||||
white-space: normal;
|
||||
}
|
||||
|
|
@ -5,5 +5,6 @@ digraph G {
|
|||
|
||||
os [label = "Operating System";shape = rect;];
|
||||
|
||||
fw -> btl -> os;
|
||||
fw -> btl -> os [style = dashed;];
|
||||
fw -> os;
|
||||
}
|
||||
|
|
@ -3,9 +3,7 @@ digraph G {
|
|||
|
||||
uboot [label = "u-boot with EFI/EBBR support";shape = rect;];
|
||||
|
||||
btl [label = "EFIBootGuard";shape = rect;];
|
||||
|
||||
kernel [label = "OS (EFI Stub + Kernel + Initramfs";shape = rect;];
|
||||
|
||||
rom -> uboot -> btl -> kernel;
|
||||
rom -> uboot -> kernel;
|
||||
}
|
||||
|
|
@ -11,4 +11,3 @@ Belden CoreOS Boot Concepts
|
|||
|
||||
overview
|
||||
uboot
|
||||
secure-boot
|
||||
|
|
|
|||
|
|
@ -63,11 +63,6 @@ machine.
|
|||
Firmware requirements
|
||||
---------------------
|
||||
|
||||
.. warning::
|
||||
|
||||
CoreOS support at the moment only hardware that contains a block storage
|
||||
device (SD Card, eMMC, ...) formatted with GPT. MBR disk or MTD device are
|
||||
not supported.
|
||||
|
||||
ARM32 / AArch32 based machine
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -75,10 +70,13 @@ ARM32 / AArch32 based machine
|
|||
The firmware for ARM32 should implement a subset of the UEFI specification, as
|
||||
defined by the EBBR Specification. As this architecure is used on old hardware,
|
||||
it's ok to use the part of the specification that are marked as deprecated or
|
||||
legacy.
|
||||
legacy like:
|
||||
|
||||
- MBR partitionning instead of GPT
|
||||
- Fixed offsets to firmware data
|
||||
|
||||
We require the firmware to provide a DeviceTree based system description and not
|
||||
an ACPI based table (as allowed by the specification).
|
||||
an ACPI based table (as allowed by the specification)
|
||||
|
||||
We also require the firmware to implement the UEFI Secure Boot functionality.
|
||||
|
||||
|
|
@ -86,12 +84,15 @@ ARM64 / AArch64 based machine
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The firmware for ARM64 should implement a subset of the UEFI specification, as
|
||||
defined by the EBBR Specification.
|
||||
defined by the EBBR Specification. The part of the specification marked as
|
||||
legacy or deprecated must not be used.
|
||||
|
||||
This means:
|
||||
- Only GPT partionning disk are supported
|
||||
- No fixed offsets to firmware data
|
||||
|
||||
We require the firmware to provide a DeviceTree based system description and not
|
||||
an ACPI based table (as allowed by the specification). The DeviceTree provided
|
||||
by the firmware can be very minimal as it can be replaced at boot time
|
||||
by a device-tree contained inside the Operating System Image.
|
||||
an ACPI based table (as allowed by the specification)
|
||||
|
||||
We also require the firmware to implement the UEFI Secure Boot functionality.
|
||||
|
||||
|
|
@ -104,13 +105,38 @@ The firmware for AMD64 should implement the UEFI specification.
|
|||
Bootloader
|
||||
==========
|
||||
|
||||
CoreOS only support `efibootguard` as bootloader. The usage of the bootloader
|
||||
is mandated.
|
||||
CoreOS only support `systemd-boot` as bootloader. The usage of the bootloader
|
||||
is optional. It's primary use case is for system that don't use a firmware
|
||||
provided by CoreOS.
|
||||
|
||||
|
||||
Operating system
|
||||
================
|
||||
|
||||
The operating system image is an UEFI application that contain the kernel. It's
|
||||
a Unified Kernel Image generated by tools from the EFIBootGuard project.
|
||||
The operating system image is an UEFI application that contain the kernel. We
|
||||
support two method to create this image:
|
||||
|
||||
Unified Kernel Images (UKI)
|
||||
---------------------------
|
||||
|
||||
This is the most secure method. The UEFI entry point is provided by
|
||||
`systemd-stub` and the image contains the Linux Kernel, the boot arguments of
|
||||
the kernel, the os-release file and an initrd ram disk.
|
||||
|
||||
This allows to have all these part authenticated via UEFI secure boot.
|
||||
|
||||
.. warning::
|
||||
UKI are not supported for ARM32 target at the moment, due to a bug in objcopy.
|
||||
See https://sourceware.org/bugzilla/show_bug.cgi?id=26218
|
||||
|
||||
.. note::
|
||||
UKI has the advantages to be discoverable by the bootloader without any
|
||||
configuration file, and doesn't need a firmware that is able to set the
|
||||
kernel command line.
|
||||
|
||||
Kernel built with the built-in EFI sub
|
||||
--------------------------------------
|
||||
|
||||
This method use the EFI stub provided by the kernel. The initramfs image has to
|
||||
be bundled with the Kernel, using `INITRAMFS_IMAGE_BUNDLE`, as otherwise it
|
||||
will not be authenticated by UEFI secure boot.
|
||||
|
|
|
|||
|
|
@ -1,268 +0,0 @@
|
|||
*******************
|
||||
Secure Boot Concept
|
||||
*******************
|
||||
|
||||
Currently CoreOS provide a Proof Of Concept of some of the secure boot element that we want to
|
||||
implement a full secure-boot solution based on UEFI secure boot.
|
||||
|
||||
The current proof of concept is structured as follows:
|
||||
|
||||
Hardware Requirements
|
||||
=====================
|
||||
|
||||
- The device must have an `eMMC`.
|
||||
- The architecture of the device must be either `ARM32` or `AARCH64`.
|
||||
|
||||
|
||||
eMMC Embedded MultiMediaCard
|
||||
============================
|
||||
|
||||
eMMC, or Embedded MultiMediaCard, represents a prevalent storage format in devices such as
|
||||
smartphones, tablets, and other embedded systems. It encapsulates NAND flash memory and a dedicated
|
||||
controller within one package. This structure not only eases integration for device manufacturers
|
||||
but also ensures a compact, efficient storage medium.
|
||||
|
||||
Within eMMC's architecture, distinct hardware partitions cater to diverse operational demands:
|
||||
|
||||
.. graphviz::
|
||||
|
||||
digraph emmcStructure {
|
||||
rankdir=TB;
|
||||
node [shape=box, style=filled, fillcolor="#e6f2ff"];
|
||||
edge [color="#0099cc", fontsize=12];
|
||||
|
||||
compound=true;
|
||||
|
||||
subgraph cluster_eMMC {
|
||||
label="eMMC";
|
||||
color="#0099cc";
|
||||
|
||||
Boot0 [label="Boot0"];
|
||||
Boot1 [label="Boot1"];
|
||||
RPMB [label="RPMB"];
|
||||
|
||||
subgraph cluster_User {
|
||||
label="User";
|
||||
color="#00cc99";
|
||||
GPT [label="GPT Table"];
|
||||
|
||||
subgraph cluster_GPT {
|
||||
label="Software Partitions (GPT)";
|
||||
color="#99e6e6";
|
||||
|
||||
SoftwarePartition1 [label="Partition 1"];
|
||||
SoftwarePartition2 [label="Partition 2"];
|
||||
SoftwarePartitionN [label="Partition N"];
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
#. **Boot0 and Boot1**: The boot partitions cater to device start-up requirements, typically hosting
|
||||
the firmware. Boot0 predominantly initiates the boot-up, while Boot1 stands as a secondary guard
|
||||
or backup, ensuring booting is resilient and failsafe.
|
||||
|
||||
#. **RPMB (Replay Protected Memory Block)**: As a secure partition, RPMB shelters data against
|
||||
potential tampering. It's tailored for sensitive information storage, such as cryptographic keys.
|
||||
Its design counters data replays or rollbacks, fortifying against particular attack types.
|
||||
|
||||
#. **User**: The primary storage domain, the User partition accommodates the OS, applications,
|
||||
and user-centric data. It's reminiscent of the primary storage drive in larger computing devices.
|
||||
Importantly, the User partition has a layered structure. Using the GPT (GUID Partition Table), it
|
||||
is further divided into multiple software partitions, which can house diverse datasets or file
|
||||
systems.
|
||||
|
||||
The boot concept of CoreOS rely on the presence of an eMMC to implement the following feature:
|
||||
|
||||
- Storage of two copy of the firmware with a way to switch from a copy to another using the eMMC
|
||||
boot0 and boot1 hardware partition
|
||||
- Storage of keys used by the UEFI Secure Key specification inside the secure RPMB hardware
|
||||
partition.
|
||||
- Storage of the bootloader, kernel and rootfs inside the user hardware partition using multiple
|
||||
software partition in the GPT format.
|
||||
|
||||
Firmware
|
||||
========
|
||||
|
||||
The firmware of the device should implement a subset of the UEFI specification as defined in the
|
||||
ARM Base Boot Requirements (EBBR) and should implement the optional UEFI Secure Boot part of the
|
||||
EBBR specifications.
|
||||
|
||||
This is done in CoreOS by levering the built-in EBBR and UEFI Secure Boot present into the u-boot
|
||||
project.
|
||||
|
||||
The hardware should verify the validity of the firmware using a hardware specific way. Then the
|
||||
generic secure boot concept explained here can be used to valide all the following component of
|
||||
CoreOS.
|
||||
|
||||
UEFI Key used by UEFI Secure Boot
|
||||
=================================
|
||||
|
||||
|
||||
- **PK (Platform Key)**: This top-tier key shoulders the responsibility of KEK verification and its
|
||||
potential revocation. PK holders have the exclusive privilege to configure the KEK and the `db`
|
||||
database. It's the gatekeeper ensuring only authorized software can touch the firmware or
|
||||
bootloader.
|
||||
|
||||
- **KEK (Key Exchange Key)**: As a medium for data exchange, the KEK is pivotal for signing the `db`
|
||||
and `dbx` databases.
|
||||
|
||||
- **db (Allowed Database)**: This is the white list. It houses the keys or hashes of permitted
|
||||
firmware and OS loaders. Execution is only granted to software with a signature that resonates
|
||||
with the keys/hashes in this database.
|
||||
|
||||
- **dbx (Forbidden Database)**: The black sheep are here. Housing keys or hashes of known
|
||||
unauthorized software, it ensures any associated software is prohibited from executing.
|
||||
|
||||
Currently all theses public keys are built-in into u-boot at build time and are read only. In the
|
||||
future we will use the OP-TEE support into u-boot to use OP-TEE to manage the keys.
|
||||
|
||||
OP-TEE and RPMB as key manager
|
||||
==============================
|
||||
|
||||
OP-TEE, or Open Portable Trusted Execution Environment, is an open-source implementation of the
|
||||
Trusted Execution Environment (TEE) designed for ARM-powered platforms. In essence, a TEE is a
|
||||
secure enclave that provides a separated, isolated environment where specific applications and their
|
||||
data can run independently from the regular operating system, ensuring they are protected against
|
||||
potential tampering or unauthorized access.
|
||||
|
||||
OP-TEE guarantees confidentiality, integrity, and authenticity for critical applications by
|
||||
executing them in this secure space. It offers a wide range of security features, including secure
|
||||
storage of cryptographic keys, secure boot, and hardware-backed crypto operations.
|
||||
|
||||
In the context of UEFI secure boot, OP-TEE becomes instrumental. UEFI's secure boot mechanism
|
||||
ensures that only trusted, signed firmware, OS loaders, and OS kernels are executed during the boot
|
||||
process. To enforce this level of trust, UEFI relies on a set of cryptographic keys, including PK
|
||||
(Platform Key), KEK (Key Exchange Key), and db/dbx (allowed and forbidden signature databases).
|
||||
Safeguarding these keys is paramount to maintain the security and integrity of the boot process.
|
||||
|
||||
By leveraging OP-TEE, these UEFI secure boot keys can be securely stored in the RPMB (Replay
|
||||
Protected Memory Block) partition of the eMMC. The RPMB is a write-protected, secure area of the
|
||||
eMMC designed to hold sensitive data and protect it against tampering and replay attacks.
|
||||
Since OP-TEE manages secure access to the RPMB partition, it ensures that the UEFI secure boot keys
|
||||
are not only safely stored but are also accessible only by authorized firmware components.
|
||||
|
||||
eMMC User Partition
|
||||
===================
|
||||
|
||||
The user partition of the eMMC must be structured using the GPT (GUID Partition Table) format.
|
||||
|
||||
Within the GPT-formatted user partition, specific partitions should be established for efficient
|
||||
booting and system operation:
|
||||
|
||||
1. **EFI**: This is the Essential Firmware Interface partition. It holds the `efibootguard`
|
||||
os-loader binary, responsible for the boot sequence's initial steps and the kernel's selection
|
||||
based on its configuration. This binary is signed with a key present in the `dbx` database
|
||||
|
||||
2. **EBG0 - Efibootguard Config 0**: This partition houses the `efibootguard` configuration for the
|
||||
first kernel option. Alongside the configuration file, it also contains a Unified Kernel Image
|
||||
(UKI), a bundled package comprising the Linux kernel, device trees, and associated boot
|
||||
components. The UKI is signed with a key present in the `dbx` database
|
||||
|
||||
3. **EBG1 - Efibootguard Config 1**: Similar to EBG0, this partition carries the `efibootguard`
|
||||
configuration for the second kernel option. It too holds a Unified Kernel Image tailored for this
|
||||
alternate boot choice.
|
||||
|
||||
4. **rootfs0**: This partition stores the CoreOS root filesystem designed to complement and operate
|
||||
with the kernel embedded in the EBG0 partition. It provides the essential system files and
|
||||
structures required for the operating system's functioning when the kernel from EBG0 is booted.
|
||||
Integrety of this rootfs is assured by storing an hash of the rootfs inside the UKI image.
|
||||
|
||||
5. **rootfs1**: Analogous to `rootfs0`, this partition houses the CoreOS root filesystem tailored
|
||||
for the kernel within the EBG1 partition. It ensures that, should the system boot from the kernel
|
||||
in EBG1, the appropriate file structures and system components are readily available.
|
||||
|
||||
EFIBootGuard Configuration
|
||||
==========================
|
||||
|
||||
Efibootguard, as a part of its design, employs a configuration system to determine the appropriate
|
||||
kernel and associated resources to boot from. This configuration is stored in distinct partitions,
|
||||
EBG0 and EBG1, each holding its configuration file.
|
||||
|
||||
The configuration file itself comprises several fields, but most crucially, it contains a revision
|
||||
field. This field is a numerical identifier indicating the version or update level of the contained
|
||||
kernel and resources. When the system initiates its boot sequence, Efibootguard assesses the
|
||||
revision values in both the EBG0 and EBG1 configuration files.
|
||||
|
||||
The selection process is straightforward yet robust: Efibootguard chooses the partition with the
|
||||
higher revision value. By doing so, it inherently opts for the most recent or updated kernel version
|
||||
available. However, this system also supports failover mechanisms. In case the kernel in the
|
||||
partition with the higher revision encounters issues during boot, Efibootguard can revert to the
|
||||
other partition, ensuring resilience and continuity in system operations.
|
||||
|
||||
Moreover, the choice isn't rigidly fixed. When the system undergoes updates, the configuration files
|
||||
can be rewritten, and the revision values adjusted, allowing for dynamic and flexible booting in
|
||||
line with system evolutions and updates. In essence, Efibootguard, with its configuration-based
|
||||
approach, ensures a blend of up-to-date system booting and built-in fail-safes for dependable
|
||||
operation.
|
||||
|
||||
Unified Kernel Image
|
||||
====================
|
||||
|
||||
After having choosen the right configuration file, Efibootguard takes on the responsibility of
|
||||
launching the Unified Kernel Image (UKI) linked with the active configuration. This image bundle
|
||||
together essential boot components like the Linux kernel, device trees, and the kernel command
|
||||
line. The secure initiation of this image is paramount, and Efibootguard ensures this by leveraging
|
||||
UEFI's start_image system call.
|
||||
|
||||
The UEFI start_image system call verifies the image's signature against the Secure Boot keys
|
||||
(PK, KEK, db, and potentially dbx). If the signature matches, indicating that the image is trusted
|
||||
and hasn't been tampered with, the image is permitted to execute. If not, the booting halts,
|
||||
preventing any unauthorized or potentially malicious code from running.
|
||||
|
||||
Once the UKI has been securely initiated, it undertakes multiple tasks. It first extracts the
|
||||
necessary components from the bundled package, identifying and utilizing the appropriate device
|
||||
trees based on `compatible` node, by matching with the `compatible` node of the `device-tree` that
|
||||
is built into the firmware. These device trees inform the system about the hardware configuration,
|
||||
ensuring the kernel interacts correctly with the system's components.
|
||||
|
||||
The UKI os-launcher also has CoreOS specialized patches, enabling dynamic rootfs switching without
|
||||
requiring an initramfs by changing the `root=` part of the kernel command line at run time to
|
||||
point to the right rootfs partition.
|
||||
|
||||
RootFS and dm-verity
|
||||
====================
|
||||
|
||||
dm-verity is a Linux kernel feature designed to provide transparent integrity checking of block
|
||||
devices, particularly for read-only file systems. Rooted in cryptographic principles, dm-verity
|
||||
employs a hash-based approach to ensure and validate the integrity of the root filesystem (rootfs).
|
||||
|
||||
The way dm-verity operates is by building a Merkle tree, a structure where each leaf node contains a
|
||||
hash of a block of the underlying data, while each non-leaf node is a hash of its children. The
|
||||
topmost node, the root of the Merkle tree, provides a cumulative hash representing the entirety of
|
||||
the data. This top hash, known as the root hash, serves as a concise, cryptographic representation
|
||||
of the entire filesystem's state.
|
||||
|
||||
When integrating dm-verity with the Unified Kernel Image (UKI), an additional layer of security is
|
||||
established. By embedding the root hash into the signed UKI, any tampering or modification in the
|
||||
rootfs can be swiftly detected. When the system boots, the UKI, being signed, ensures that the
|
||||
embedded root hash is legitimate and untampered. As the OS accesses the rootfs, dm-verity
|
||||
recalculates the hash values in real-time and compares them to the values in the original Merkle
|
||||
tree, referenced by the embedded root hash.
|
||||
|
||||
If any discrepancies are found – that is, if the recalculated hash doesn't match the stored value –
|
||||
it indicates potential tampering, and the OS can halt access or take appropriate measures.
|
||||
|
||||
.. graphviz::
|
||||
|
||||
digraph SecureBootFlow {
|
||||
rankdir=TB;
|
||||
|
||||
node [shape=box, style=filled, fillcolor="#e6f2ff"];
|
||||
edge [color="#0099cc", fontsize=12];
|
||||
|
||||
Hardware [label="Hardware\n(ARM32/AARCH64 with eMMC)"];
|
||||
Firmware [label="u-boot Firmware\n(UEFI EBRR subset)"];
|
||||
eMMCConfig [label="eMMC Configuration\n(GPT with EFI partition)"];
|
||||
EFIBootGuard [label="EFIBootGuard\n(A/B Kernel Switching)"];
|
||||
UnifiedKernel [label="Unified Kernel Image\n(Kernel, cmd line, DTB)"];
|
||||
KernelAndRootFS [label="Kernel & RootFS\n(dm-verity validation)"];
|
||||
|
||||
Hardware -> Firmware [label="Flashed with u-boot\n+ Built-in keys"];
|
||||
Firmware -> eMMCConfig [label="eMMC boot"];
|
||||
eMMCConfig -> EFIBootGuard [label="Boots from EFI partition"];
|
||||
EFIBootGuard -> UnifiedKernel [label="Selects kernel A/B"];
|
||||
UnifiedKernel -> KernelAndRootFS [label="Kernel boot\n+ RootFS verification"];
|
||||
|
||||
}
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
digraph G {
|
||||
start [label = "boot";];
|
||||
|
||||
mb [label = "Detect the main board name";shape = rect;];
|
||||
|
||||
mbdts [label = "Load main board device tree";shape = rect;];
|
||||
|
||||
ext [label = "Detect the extension module name";shape = rect;];
|
||||
extdts [label = "Load a device tree overlay for each module";shape = rect;];
|
||||
|
||||
dtsprocess [label = "Add and remove device tree node as needed (DT Fixup)";shape = rect;];
|
||||
|
||||
stop [label = "Start UEFI application";];
|
||||
|
||||
start -> mb -> mbdts -> ext -> extdts -> dtsprocess -> stop;
|
||||
}
|
||||
|
|
@ -21,10 +21,13 @@ to be changed at runtime.
|
|||
Device tree handling
|
||||
====================
|
||||
|
||||
As per the EBBR specification, the firmware is responsible to provide a
|
||||
device tree to the kernel. Not that it's OK to export the device tree used by
|
||||
U-Boot internally as it will be replaced by a propper device tree at a later
|
||||
stage. This avoid the need to load the device tree from a boot partition.
|
||||
As per the EBBR specification, the firmware is responsible to provide the
|
||||
device tree to the kernel.
|
||||
|
||||
This means that loading the main device tree and all the device tree overlay are
|
||||
is the responsibility of the firmware.
|
||||
|
||||
.. graphviz:: uboot-dts-handling.dot
|
||||
|
||||
Features to implement per machine
|
||||
=================================
|
||||
|
|
@ -32,11 +35,19 @@ Features to implement per machine
|
|||
The u-boot provided by CoreOS should implement the following features for each
|
||||
supported machine:
|
||||
|
||||
board_fit_config_name_match
|
||||
----------------------------
|
||||
|
||||
This allows u-boot to select the device tree to use dynamically using board
|
||||
detection. See `README.multi-dtb-fit`
|
||||
|
||||
|
||||
extension_board_scan
|
||||
--------------------
|
||||
|
||||
The extension_board_scan function has to be implemented. This function should
|
||||
return the list of add-ons board detected.
|
||||
return the list of add-ons board detected, with the filename of the
|
||||
correspondig device-tree overlay.
|
||||
|
||||
DT Fixup
|
||||
--------
|
||||
|
|
@ -44,3 +55,53 @@ DT Fixup
|
|||
U-Boot can create, modify and remove node from the device tree dynamically
|
||||
before starting the kernel. This can be used to pass dynamic information stored
|
||||
inside a "board descriptor" eeprom or CPLD to the Kernel.
|
||||
|
||||
Custom Features that are generic
|
||||
================================
|
||||
|
||||
The u-boot provided by CoreOS should implement the following custom features:
|
||||
|
||||
File authentication
|
||||
-------------------
|
||||
|
||||
In order to be able to authenticate device tree, device-tree overlay file or
|
||||
other file needed by the firmware, we need a command to authenticate a file that
|
||||
was previously loaded is the `load` command.
|
||||
|
||||
.. note::
|
||||
|
||||
My proposal is to use the UEFI Capsule format, to reuse theses function from
|
||||
u-boot:
|
||||
|
||||
- **efi_capsule_authenticate**: Authenticate the UEFI capsule using a x509
|
||||
certificate built into u-boot
|
||||
- **efi_remove_auth_hdr**: Can be used to point a pointer to the start of the
|
||||
content of an authenticated capsule.
|
||||
|
||||
An UEFI Capsule is a generic container that can be signed using a x.509
|
||||
private key. The public key is stored inside u-boot (it's not the same as
|
||||
the keys used for UEFI secure-boot). See
|
||||
https://u-boot.readthedocs.io/en/v2022.10/develop/uefi/uefi.html?highlight=capsule#enabling-capsule-authentication
|
||||
|
||||
|
||||
extension_overlay_cmd
|
||||
---------------------
|
||||
|
||||
A custom command should be made for `extension_overlay_cmd`. The extension
|
||||
subsystem use the command defined as extension_overlay_cmd to load
|
||||
the overlay `${extension_overlay_name}` into `extension_overlay_addr`
|
||||
|
||||
This should reuse the file authentication mechanismus.
|
||||
|
||||
.. note::
|
||||
|
||||
A concept on where and how to securly store device tree and overlay needed
|
||||
by the kernel has to be written.
|
||||
|
||||
My proposal is to use the UEFI Capsule format, to reuse theses function from
|
||||
u-boot:
|
||||
|
||||
- **efi_capsule_authenticate**: Authenticate the UEFI capsule using a x509
|
||||
certificate built into u-boot
|
||||
- **efi_remove_auth_hdr**: Can be used to point a pointer to the start of the
|
||||
content of an authenticated capsule.
|
||||
|
|
|
|||
|
|
@ -1,104 +0,0 @@
|
|||
.. index:: EFIBOOTGUARD
|
||||
|
||||
Bootloader: EFIBootGuard
|
||||
************************
|
||||
|
||||
CoreOS use `EFIBootGuard <https://github.com/siemens/efibootguard>`_ as a
|
||||
bootloader. EFIBootGuard is the components responsible to find and load the
|
||||
right Unified Kernel Image (UKI).
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
EFIBootGuard is an UEFI application. It's installed inside the EFI System
|
||||
Partition at:
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 25
|
||||
:header-rows: 1
|
||||
|
||||
* - Platform Architecture
|
||||
- Path
|
||||
* - ARM32
|
||||
- /EFI/BOOT/bootarm.efi
|
||||
* - ARM64
|
||||
- /EFI/BOOT/bootaa64.efi
|
||||
* - x86_64
|
||||
- /EFI/BOOT/bootax64.efi
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
Configuration lookup
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When started, EFIBootGuard will scan all vFAT partition to list all the valid
|
||||
boot partition.
|
||||
|
||||
A valid boot partition is a vFAT partition that contain a valid BGENV.DAT file.
|
||||
|
||||
This file contains the following parameters:
|
||||
|
||||
- Path to a Kernel file
|
||||
- Parameter to pass to the kernel
|
||||
- Flag for in progress update
|
||||
- Update Status (OK, INSTALLED, TESTING, FAILED)
|
||||
- Watchdog timeout
|
||||
- Revision numbers
|
||||
- User data (not used)
|
||||
|
||||
Consistency of the configuration is guaranteed by a CRC check.
|
||||
|
||||
.. hint::
|
||||
CoreOS use a signed Unified Kernel Image that embed the parameters to pass
|
||||
to the Linux Kernel. Parameters from the UKI always override parameters
|
||||
set inside the EFIBootGuard configuration file.
|
||||
|
||||
This is a security measure to ensure that only a signed kernel parameters is
|
||||
used (secure boot).
|
||||
|
||||
Booting
|
||||
~~~~~~~
|
||||
|
||||
EFIBootGuard will try to load a kernel using the parameters from the
|
||||
configuration with the higher revision number.
|
||||
|
||||
Update Handling
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Before booting, EFIBootGuard will check the state flags inside the configuration
|
||||
file.
|
||||
|
||||
If it's OK it means that it's a valid configuration.
|
||||
|
||||
If the state is INSTALLED, it's mean that a new image was flash but was never
|
||||
booted. EFIBootGuard will change the state to TESTING then boot the kernel.
|
||||
|
||||
If the state is TESTING, it's mean that the kernel was already booted one time,
|
||||
but the running system has not marked the update as working. EFIBootGuard will
|
||||
set the status to FAILED and set the revision number to 0 and boot another
|
||||
configuration.
|
||||
|
||||
.. hint::
|
||||
To mark the update as working from a running system, you can use the
|
||||
following command::
|
||||
|
||||
bg_setenv --confirm
|
||||
|
||||
This should be done after an update to tell the bootloader that the new
|
||||
system image is working. CoreOS doesn't do it automatically for now.
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 15 85
|
||||
:header-rows: 1
|
||||
|
||||
* - Bugs
|
||||
- Description
|
||||
* - `#370558 <https://tp.gad.local/entity/370558>`_
|
||||
- On machine use a Marvel CN913x CPU like the cn9130-cf-pro machine, the version
|
||||
of U-Boot provided don't provide the UEFI api needed by EFIBootGuard to update
|
||||
his configuration file at boot time. EFIBootGuard is not able to detect
|
||||
a failed update.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
======================
|
||||
CoreOS Core Components
|
||||
======================
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
Firmware: U-Boot <u-boot>
|
||||
Bootloader: EFIBootGuard <efibootguard>
|
||||
Kernel: Unified Kernel Image <kernel>
|
||||
Init System: SystemD <systemd>
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
.. index:: UKI
|
||||
|
||||
Kernel: Unified Kernel Image
|
||||
*****************************
|
||||
|
||||
CoreOS use by default a `Unified Kernel Image (UKI) <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md>`_
|
||||
generated by tools from the EFIBootGuard project.
|
||||
|
||||
An UKI is a EFI app that load in memory multiple artifacts needed by the Linux
|
||||
Kernel before loading and booting the Linux Kernel itself:
|
||||
|
||||
* The kernel commands line is always loaded from the UKI
|
||||
* A device-tree file: UKI can contain multiple UKI and will load the one
|
||||
matching the device-tree file passed by the firmware.
|
||||
|
||||
Known Issues and unimplemented feature
|
||||
--------------------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
Bundling an INITRD image into the UKI is not implemented yet.
|
||||
|
||||
.. danger::
|
||||
|
||||
The Unified Kernel Image is signed but CoreOS currently provide no way to
|
||||
verify the integrity of the choosed ROOTFS partition as CoreOS doesn't
|
||||
provide an end-to-end secure boot solution yet.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. index:: SYSTEMD
|
||||
|
||||
Init System: SystemD
|
||||
********************
|
||||
|
||||
`SystemD <https://www.freedesktop.org/wiki/Software/systemd/>`_ is used as
|
||||
init system in CoreOS.
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
.. index:: UBOOT
|
||||
|
||||
Firmware: U-Boot
|
||||
****************
|
||||
|
||||
.. hint::
|
||||
CoreOS should work with any UEFI compliant firmware. Using U-Boot is not
|
||||
mandatory.
|
||||
|
||||
`U-Boot <https://u-boot.readthedocs.io/en/latest/>`_ is built by default with
|
||||
UEFI enabled and secure boot enabled. UEFI secure boot related keys are
|
||||
installed at build time and can't be changed from the U-Boot command line.
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
U-Boot will boot the default UEFI application from the EFI System Partition.
|
||||
|
||||
The path to the default UEFI application is architecture dependent:
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 25
|
||||
:header-rows: 1
|
||||
|
||||
* - Platform Architecture
|
||||
- Path
|
||||
* - ARM32
|
||||
- /EFI/BOOT/bootarm.efi
|
||||
* - ARM64
|
||||
- /EFI/BOOT/bootaa64.efi
|
||||
* - x86_64
|
||||
- /EFI/BOOT/bootax64.efi
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
.. danger::
|
||||
|
||||
The U-Boot configuration used by CoreOS currently was not reviewed for
|
||||
security issue and is not safe (access to u-boot command line is allowed).
|
||||
|
||||
.. danger::
|
||||
|
||||
CoreOS U-Boot configuration enable UEFI Secure Boot but the U-Boot binary
|
||||
itself is not validated. Thus we don't provide a full end-to-end secure boot
|
||||
solution yet.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
==========================
|
||||
CoreOS Optional Components
|
||||
==========================
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
Network Manager: NetworkManager <networkmanager>
|
||||
SSH Server: OpenSSH <openssh>
|
||||
Container: Podman <podman>
|
||||
CoreOS Installer <installer>
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
.. index:: COREOS_INSTALLER
|
||||
|
||||
CoreOS Installer
|
||||
****************
|
||||
|
||||
The CoreOS installer is a set of scripts running on the target and a
|
||||
corresponding bitbake image that is used into the bootstrap process of CoreOS.
|
||||
|
||||
coreos-image-installer
|
||||
======================
|
||||
|
||||
The CoreOS image installer results in an image contairing only a single binary
|
||||
EFI file. This EFI file includes a kernel, a device tree and an initramfs with
|
||||
all (and only) the tools needed to install CoreOS.
|
||||
|
||||
The installer image is not automatically built in parallel of a normal image.
|
||||
This can be changed by setting `COREOS_IMAGE_GENERATE_INSTALLER` to 1 in the
|
||||
image file (as it is done for example in coreos-image-all-features.bb).
|
||||
|
||||
The installer image build by default only a single EFI binary named
|
||||
coreos-installer-MACHINE.efi. An SDCard or USB image can be generated if
|
||||
`COREOS_INSTALLER_WKS_FILE` is set to a wks file.
|
||||
|
||||
coreos-installer
|
||||
================
|
||||
|
||||
The coreos-installer recipe installs scripts that are used at startup to
|
||||
automatically format the internal emmc of the device. The recipe also contains
|
||||
a swupdate configuration file to setup swupdate correctly for that use case.
|
||||
|
||||
coreos-installer-config
|
||||
=======================
|
||||
|
||||
The coreos-installer-config recipe installs device specific configuration file
|
||||
used by the coreos-installer. This includes the partitioner config file. Distros
|
||||
and projects based on CoreOS can change the partioning scheme or partition size
|
||||
by installing their own version of this package using a `bbappend file`.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
.. index:: NETWORKMANAGER
|
||||
|
||||
Network Manager: NetworkManager
|
||||
*******************************
|
||||
|
||||
You can add `NetworkManager <https://networkmanager.dev/>`_ to an image that
|
||||
inherit from `coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "networkmanager"
|
||||
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
.. index:: OPENSSH
|
||||
|
||||
SSH Server: OpenSSH
|
||||
*******************
|
||||
|
||||
You can add an `OpenSSH <https://www.openssh.com/>`_ based ssh server to an
|
||||
image that inherit from `coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "ssh-server"
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
.. index:: PODMAN
|
||||
|
||||
Container: Podman
|
||||
*****************
|
||||
|
||||
You can add `Podman <https://podman.io/>`_ to an image that inherit from
|
||||
`coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "podman"
|
||||
|
|
@ -112,10 +112,6 @@ except ImportError:
|
|||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
html_css_files = [
|
||||
'css/coreos.css',
|
||||
]
|
||||
|
||||
# Hide 'Created using Sphinx' text
|
||||
html_show_sphinx = False
|
||||
|
||||
|
|
|
|||
|
|
@ -1,61 +0,0 @@
|
|||
.. _beaglebone:
|
||||
|
||||
**********
|
||||
BeagleBone
|
||||
**********
|
||||
|
||||
.. important::
|
||||
|
||||
The BeagleBone target uses an old TI AM3358 ARM 32 BIT CPU. This processor
|
||||
of the AM335x family is used in a lot of current and legacy device at
|
||||
Hirschmann and NetModule. Thus we only support this target to ensure
|
||||
that our architecture is working on older architecture too.
|
||||
|
||||
CoreOS build instruction
|
||||
========================
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=beaglebone bitbake coreos-image-all-features
|
||||
cd tmp/deploy/images/beaglebone
|
||||
|
||||
.. list-table:: Image artifacts for BeagleBone
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Filename
|
||||
- Description
|
||||
* - <IMAGE>-beaglebone.swu
|
||||
- System image bundle used by the CoreOS installer or the CoreOS updater
|
||||
* - <IMAGE>-beaglebone.wic.xz
|
||||
- System image for SDCard
|
||||
* - coreos-image-installer-beaglebone.wic.xz
|
||||
- CoreOS installer image for SD Card
|
||||
|
||||
.. hint::
|
||||
|
||||
Only the .swu image is need if you have already a working installation of CoreOS
|
||||
running on the board that you want to update.
|
||||
|
||||
CoreOS Pre-installation guide
|
||||
=============================
|
||||
|
||||
If you want to use the internal emmc storage as boot target, you will need to
|
||||
flash coreos-image-installer-beaglebone.wic.xz to your SDCard using bmaptool.
|
||||
|
||||
If you want to use the sdcard as boot target, you will need to flash
|
||||
<IMAGE>-beaglebone.wic.xz to your SDCard using bmaptool.
|
||||
|
||||
By default the board boot on the internal emmc storage. To boot with a SDCard
|
||||
instead, you will need to push the S2 button (boot switch) while powering up the
|
||||
board.
|
||||
|
||||
.. image:: beaglebone/beaglebone-s2-switch.png
|
||||
|
||||
Serial access is available on the 5-pin header. See
|
||||
`this page <https://elinux.org/Beagleboard:BeagleBone_Black_Serial>`_ for
|
||||
more info on the serial connector.
|
||||
|
||||
Now that you have the installer running, CoreOS can be installed by following
|
||||
the :ref:`generic installation manual<Installation Manual>` using the SDCard
|
||||
mehtod.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 246 KiB |
|
|
@ -1,126 +0,0 @@
|
|||
.. _netmodule-hw34:
|
||||
|
||||
*******************************
|
||||
NetModule HW34 (XG900 A-Sample)
|
||||
*******************************
|
||||
|
||||
.. important::
|
||||
|
||||
netmodule-hw34 support is currently only available on the features branch
|
||||
feat/netmodule-bsp
|
||||
|
||||
.. image:: netmodule-hw34/hw34.png
|
||||
|
||||
CoreOS build instruction
|
||||
========================
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=netmodule-hw34 bitbake coreos-image-all-features
|
||||
cd tmp/deploy/images/netmodule-hw34
|
||||
|
||||
.. list-table:: Image artifacts for NetModule HW32
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Filename
|
||||
- Description
|
||||
* - <IMAGE>-netmodule-hw34.swu
|
||||
- System image bundle used by the CoreOS installer or the CoreOS updater
|
||||
* - coreos-installer-netmodule-hw34.efi
|
||||
- CoreOS installer bundled in a single EFI binary
|
||||
* - tiboot3.bin
|
||||
- SPL Bootloader for the wakeup domain (arm32 R5 core)
|
||||
* - tispl.bin
|
||||
- SPL bootloader for the main domain (aarch64 main core)
|
||||
* - u-boot.bin
|
||||
- Third stage bootloader the main domain (aarch64 main core)
|
||||
|
||||
.. hint::
|
||||
|
||||
Only the .swu image is need if you have already a working installation of CoreOS
|
||||
running on the board that you want to update.
|
||||
|
||||
CoreOS Pre-installation guide
|
||||
=============================
|
||||
|
||||
The CoreOS installation process expect a working EFI firmware based on u-boot
|
||||
running on the board.
|
||||
|
||||
For board that have no firmware or a defect firmware, we can provide the firmware by
|
||||
booting over USB.
|
||||
|
||||
First, we need to put the board in USB Boot mode by modifying the dip-switch
|
||||
on the back of the board:
|
||||
|
||||
.. code-block::
|
||||
|
||||
ON
|
||||
S500 ▄ ▀ ▄ ▀ ▄ ▄ ▄ ▄
|
||||
1 2 3 4 5 6 7 8
|
||||
|
||||
.. hint::
|
||||
|
||||
Unflashed board or board without a valid tiboot3.bin image will default to
|
||||
USB boot mode, so settings the dip-switch may be skipped in this case.
|
||||
|
||||
Then you need to populate the jumper X600 near the USB port:
|
||||
|
||||
.. image:: netmodule-hw34/hw34-usb-device.png
|
||||
|
||||
Then power-up the board by first apply 12V throug the main connector, then
|
||||
connect a USB-C cable. Console access to the board can be accessed using the
|
||||
serial port on the main connector.
|
||||
|
||||
|
||||
.. important::
|
||||
|
||||
When removing the power, ensure that the USB cable is removed first. Otherwise
|
||||
the processor will not get shutdown properly
|
||||
|
||||
|
||||
Now you should see the board from you computer:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
lsusb | grep DFU
|
||||
Bus 003 Device 048: ID 0451:6165 Texas Instruments, Inc. AM64x DFU
|
||||
|
||||
Now we start downloading the bootloaders into RAM by using dfu-utils:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
dfu-util -D tiboot3.bin -a 0
|
||||
dfu-util -D tispl.bin -a 0
|
||||
|
||||
# Eject and start execution of tispl
|
||||
dfu-util -e -a 0
|
||||
dfu-util -D u-boot.img -a 1
|
||||
|
||||
# Eject ans tart of u-boot.img
|
||||
dfu-util -e -a 1
|
||||
|
||||
.. hint::
|
||||
|
||||
The firmware was uploaded to the RAM, thus will not survice a reboot.
|
||||
|
||||
|
||||
Now that we have a firmware running, CoreOS can be installed by following
|
||||
the :ref:`generic installation manual<Installation Manual>`.
|
||||
|
||||
|
||||
CoreOS Post-Installation
|
||||
========================
|
||||
|
||||
When the installation of CoreOS is done, power down the board by first
|
||||
removing the USB-C cable then the main power.
|
||||
|
||||
Now, put the board back in emmc boot mode:
|
||||
|
||||
.. code-block::
|
||||
|
||||
ON
|
||||
S500 ▀ ▄ ▄ ▀ ▄ ▄ ▄ ▄
|
||||
1 2 3 4 5 6 7 8
|
||||
|
||||
Then power-up the board again and CoreOS should boot.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 3.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 MiB |
|
|
@ -1,33 +0,0 @@
|
|||
******************
|
||||
Supported Hardware
|
||||
******************
|
||||
|
||||
.. _Hardware Overview:
|
||||
.. list-table:: Supported BitBake MACHINE
|
||||
:widths: 25 75 25
|
||||
:header-rows: 1
|
||||
|
||||
* - BitBake MACHINE
|
||||
- Compatible hardware
|
||||
- Documentation
|
||||
* - cn9131-bldn-mbv
|
||||
- Falcon A3 Sample
|
||||
-
|
||||
* - netmodule-hw34
|
||||
- NetModule HW34 (XG900 Sample)
|
||||
- :ref:`🔗 links <netmodule-hw34>`
|
||||
* - cn9130-cf-pro
|
||||
- Solidrun cn9130-cf-pro
|
||||
-
|
||||
* - beaglebone
|
||||
- Beaglebone, Beaglebone Black, Beaglebone Green
|
||||
- :ref:`🔗 links <beaglebone>`
|
||||
* - vm-x64
|
||||
- Virtual Machine
|
||||
-
|
||||
|
||||
.. hint::
|
||||
|
||||
Please contact the CoreOS team when starting a new project based on CoreOS
|
||||
or want to contribute the hardware support for an existing Hardware.
|
||||
|
||||
|
|
@ -26,31 +26,14 @@ same structures.
|
|||
Setting up a CoreOS based distro <using-coreos>
|
||||
Building and using a Container Image <using-container>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Supported Hardware
|
||||
|
||||
Overview <hardware/overview>
|
||||
NetModule HW34 (XG900 Sample) <hardware/netmodule-hw34>
|
||||
BeagleBone <hardware/beaglebone>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Manuals
|
||||
|
||||
Installation Manual <installation/index>
|
||||
Reference Manual <ref-manual/index>
|
||||
Testing Manual <testing/index>
|
||||
Boot Concepts <boot/index>
|
||||
Best Practices <best_practices/index>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Software Components
|
||||
|
||||
Core Components <components/core/index>
|
||||
Optional Components <components/optional/index>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Indexes
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
|
||||
.. _Installation Manual:
|
||||
|
||||
======================================
|
||||
Belden CoreOS EMMC Installation Manual
|
||||
======================================
|
||||
|
||||
.. important::
|
||||
|
||||
This manual expect that the board you want to install CoreOS on have a
|
||||
running UEFI firmware based on u-boot. Information about how to get console
|
||||
access and a running firmware can be found for your hardware in the
|
||||
:ref:`Hardware Overview <Hardware Overview>`
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
starting
|
||||
partitionning
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
************
|
||||
Installation
|
||||
************
|
||||
|
||||
The installer automatically creates all the needed partitions when starting up.
|
||||
|
||||
Now you have to upload the .swu file to start the flashing process.
|
||||
|
||||
Choose one of these methods to upload the system image to the installer:
|
||||
|
||||
Upload the .swu file over the network using a browser
|
||||
=====================================================
|
||||
|
||||
|
||||
Now you can install the desired CoreOS version by uploading the desired
|
||||
.swu file to the board using a browser, by going to http://<TARGET_IP>:8080
|
||||
|
||||
Upload the .swu file over the network using devtool
|
||||
===================================================
|
||||
|
||||
If you have a working build environement, you can upload the image using
|
||||
the devtool command:
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=<MACHINE> devtool swupdate-www-push <IMAGE> <TARGET_IP>
|
||||
|
||||
|
||||
.. hint::
|
||||
Replace <IMAGE> with the image recipe name, eg: coreos-image-all-features
|
||||
Replace <MACHINE> by the machine name (if not set in local.conf)
|
||||
Replace <TARGET_IP> by the IP adress of the board
|
||||
|
||||
Upload the .swu file over the network using coreos-device
|
||||
=========================================================
|
||||
|
||||
If you don't have a working build environement, you can upload the image using
|
||||
the coreos-device python script:
|
||||
|
||||
.. code-block::
|
||||
|
||||
./coreos-device swupdate-www-push <SWU_PATH> <TARGET_IP>
|
||||
|
||||
.. hint::
|
||||
Replace <SWU_PATH> with the the path to the SWU, eg: ./coreos-image-all-features-<MACHINE>.swu
|
||||
Replace <TARGET_IP> by the IP adress of the board
|
||||
|
||||
.. hint::
|
||||
You will find the coreos-device script under the scripts directory inside
|
||||
the CoreOS repository.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
**********************
|
||||
Starting the installer
|
||||
**********************
|
||||
|
||||
Choose one of these methods to start the bootloader:
|
||||
|
||||
Starting the installer over the network with TFTP
|
||||
=================================================
|
||||
|
||||
Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into an
|
||||
accessible TFTP server, then enter the following command into u-boot:
|
||||
|
||||
.. code-block::
|
||||
|
||||
setenv ipaddr <TARGET_IP>; setenv serverip <SERVER_IP>;
|
||||
tftp $loadaddr coreos-installer-<MACHINE>.efi
|
||||
bootefi $loadaddr
|
||||
|
||||
.. hint::
|
||||
|
||||
Replace <TARGET_IP> by a valid IP adress for the target, eg: 192.168.1.1
|
||||
Replace <SERVER_IP> by the IP adress of the server, eg: 192.168.1.254
|
||||
Replace <MACHINE> by the name of the machine set in bitbake
|
||||
|
||||
Starting the installer over the network with DHCP/BOOTP/TFTP
|
||||
============================================================
|
||||
|
||||
Use a DHCP/BOOTP/TFTP server to configure automatically the device. You can
|
||||
use dnsmasq for this task.
|
||||
|
||||
|
||||
.. code-block: ini
|
||||
|
||||
interface=<INTERFACE>
|
||||
|
||||
dhcp-range=<INTERFACE>,10.237.30.2,10.237.30.100,4h
|
||||
dhcp-range=<INTERFACE>,10.237.40.2,10.237.40.100,4h
|
||||
|
||||
enable-tftp
|
||||
dhcp-boot=tag:<INTERFACE>,coreos-installer-<MACHINE>.efi
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
.. hint::
|
||||
|
||||
Replace <INTERFACE> by the name of the network interface that is connected
|
||||
to the target. Eg: enp3s0
|
||||
Replace <MACHINE> by the name of the machine set in bitbake
|
||||
|
||||
Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into the
|
||||
/var/lib/tftpboot folder then enter the following command into u-boot:
|
||||
|
||||
.. code-block::
|
||||
|
||||
setenv autoload yes
|
||||
setenv autostart no
|
||||
dhcp
|
||||
bootefi $loadaddr
|
||||
|
||||
Starting the installer using an SD Card
|
||||
=======================================
|
||||
|
||||
Flash the coreos-image-installer.wic.xz into an SDCard and put the board
|
||||
in SDCard boot mode. Insert the SDCard and power up the board. The CoreOS
|
||||
installer should start automatically.
|
||||
|
|
@ -46,7 +46,7 @@ Theses packages are needed on your build machine:
|
|||
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils \
|
||||
debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \
|
||||
libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd \
|
||||
liblz4-tool bmap-tools efitools openssl sbsigntool python3-click \
|
||||
liblz4-tool bmap-tools efitools openssl sbsign python3-click \
|
||||
python3-aiohttp
|
||||
|
||||
Use Git to clone CoreOS
|
||||
|
|
|
|||
|
|
@ -10,14 +10,9 @@ to Belden CoreOS.
|
|||
Machine Features
|
||||
================
|
||||
|
||||
CoreOS doesn't define any custom machine feature for now, but the
|
||||
:external:ref:`MACHINE_FEATURES <ref-features-machine>` of OpenEmbedded-Core
|
||||
can be used with CoreOS.
|
||||
|
||||
In addition, those CoreOS specific MACHINE_FEATURES can be used too:
|
||||
|
||||
- *sdcard:* the machine as an internal SD Card or MicroSD Slot.
|
||||
- *emmc:* the machine as an internal emmc based storage
|
||||
|
||||
can be used.
|
||||
|
||||
.. index:: DISTRO_FEATURES
|
||||
|
||||
|
|
|
|||
|
|
@ -1,354 +0,0 @@
|
|||
.. index:: BATS
|
||||
|
||||
************************************
|
||||
BATS - Bash Automated Testing System
|
||||
************************************
|
||||
|
||||
The CoreOS distribution supports writing tests using shell syntax by providing the `bats` command.
|
||||
|
||||
If you want to use `bats`, you will need the following CoreOS packages:
|
||||
|
||||
- bats
|
||||
- bats-file
|
||||
- bats-assert
|
||||
|
||||
Overview of BATS
|
||||
================
|
||||
|
||||
A BATS test can be as simple as a single .bats file. For example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
|
||||
@test "can output to stdout" {
|
||||
run echo hello
|
||||
assert_output 'hello'
|
||||
}
|
||||
|
||||
You can run it using the command `bats <filename>.bats`
|
||||
|
||||
This will give you the following output:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats <filename>.bats
|
||||
<filename>.bats
|
||||
✓ can output to stdout
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
The run command
|
||||
================
|
||||
|
||||
In shell tests, you often need to run commands and capture their output, exit
|
||||
status, and error messages. The run command provided by `bats` allows you to
|
||||
execute commands within your test cases and collect this information for later
|
||||
assertion and validation.
|
||||
|
||||
The run command will make the following variables available:
|
||||
|
||||
- `${status}`: exit code of the command run by `run`
|
||||
- `${output}`: combined content of `stdout` and `stderr`
|
||||
- `${lines[@]}`: array of lines of the output
|
||||
- `${BATS_RUN_COMMAND}`: command run by the `run` command
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "invoking foo with a nonexistent file prints an error" {
|
||||
run foo nonexistent_filename
|
||||
[ "$status" -eq 1 ]
|
||||
[ "$output" = "foo: no such file 'nonexistent_filename'" ]
|
||||
[ "$BATS_RUN_COMMAND" = "foo nonexistent_filename" ]
|
||||
|
||||
}
|
||||
|
||||
The `run` command accepts some parameters:
|
||||
|
||||
- `-N`: Expect N as exit status and fail otherwise
|
||||
- `-!`: Expect non-zero exit status and fail if the command succeeds.
|
||||
- `--keep-empty-lines`: don't remove empty lines from `${lines}`
|
||||
- `--separate-stderr`: Use separate variables for stderr `${stderr}` and `${stderr_lines[@]}`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "invoking foo without arguments prints usage" {
|
||||
run -1 foo
|
||||
[ "${lines[0]}" = "usage: foo <filename>" ]
|
||||
}
|
||||
|
||||
The bats-assert helper
|
||||
======================
|
||||
|
||||
The `bats-assert` helper provides some functions to create more readable tests.
|
||||
These assertions use the variables created by the `run` command and can be used
|
||||
as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test 'assert_output()' {
|
||||
run echo 'have'
|
||||
assert_output 'want'
|
||||
}
|
||||
|
||||
The following functions are provided:
|
||||
|
||||
- `assert` and `refute`: Assert that a given expression evaluates to true or false.
|
||||
- `assert_equal`: Assert that two parameters are equal.
|
||||
- `assert_not_equal`: Assert that two parameters are not equal.
|
||||
- `assert_success` and `assert_failure`: Assert that the exit status is 0 or 1.
|
||||
- `assert_output` and `refute_output`: Assert that the output does (or does not) contain the given content.
|
||||
- `assert_line` and `refute_line`: Assert that a specific line of the output does (or does not) contain the given content.
|
||||
- `assert_regex` and `refute_regex`: Assert that a parameter matches (or does not match) the given pattern.
|
||||
|
||||
The bats-file helper
|
||||
====================
|
||||
|
||||
The `bats-file` helper provides functions to help work with files in tests:
|
||||
|
||||
**Test File Types:**
|
||||
|
||||
- `assert_exists` and `assert_not_exists`: Check if a file or directory exists.
|
||||
- `assert_file_exists` and `assert_file_not_exists`: Check if a file exists.
|
||||
- `assert_dir_exists` and `assert_dir_not_exists`: Check if a directory exists.
|
||||
- `assert_link_exists` and `assert_link_not_exists`: Check if a link exists.
|
||||
- `assert_block_exists` and `assert_block_not_exists`: Check if a block special file exists.
|
||||
- `assert_character_exists` and `assert_character_not_exists`: Check if a character special file exists.
|
||||
- `assert_socket_exists` and `assert_socket_not_exists`: Check if a socket exists.
|
||||
- `assert_fifo_exists` and `assert_fifo_not_exists`: Check if a fifo special file exists.
|
||||
|
||||
**Test File Attributes:**
|
||||
|
||||
- `assert_file_executable` and `assert_file_not_executable`
|
||||
- `assert_file_owner` and `assert_file_not_owner`
|
||||
- `assert_file_permission` and `assert_not_file_permission`
|
||||
- `assert_file_size_equals`
|
||||
- `assert_size_zero` and `assert_size_not_zero`
|
||||
- `assert_file_group_id_set` and `assert_file_not_group_id_set`
|
||||
- `assert_file_user_id_set` and `assert_file_not_user_id_set`
|
||||
- `assert_sticky_bit` and `assert_no_sticky_bit`
|
||||
|
||||
**Test File Content:**
|
||||
|
||||
- `assert_file_empty` and `assert_file_not_empty`
|
||||
- `assert_file_contains` and `assert_file_not_contains`
|
||||
- `assert_symlink_to` and `assert_not_symlink_to`
|
||||
|
||||
**Working with a temporary directory:**
|
||||
|
||||
- `temp_make` and `temp_del`
|
||||
|
||||
Pre- and Post-test case hooks
|
||||
==============================
|
||||
|
||||
In some cases, it's useful to have a function that runs before or after each test
|
||||
case in a bats file.
|
||||
|
||||
A function named `setup` will run before each test case, and a function
|
||||
named `teardown` will run after each test case.
|
||||
|
||||
This example creates a directory in the setup function but lacks a teardown
|
||||
that removes the directory. The second time the setup function is run, the
|
||||
setup will fail as the directory already exists:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup() {
|
||||
mkdir tmp
|
||||
echo 'a' >> ./tmp/test
|
||||
}
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats test.bats
|
||||
test.bats
|
||||
✓ test contains a single a I
|
||||
✗ test contains a single a II
|
||||
(from function `setup' in test file test.bats, line 8)
|
||||
`mkdir tmp' failed
|
||||
mkdir: cannot create directory ‘tmp’: File exists
|
||||
|
||||
2 tests, 1 failure
|
||||
|
||||
This can be easily fixed by adding a teardown function:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup() {
|
||||
mkdir tmp
|
||||
echo 'a' >> ./tmp/test
|
||||
}
|
||||
|
||||
teardown() {
|
||||
rm -rf ./tmp
|
||||
}
|
||||
|
||||
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats test.bats
|
||||
test.bats
|
||||
✓ test contains a single a I
|
||||
✓ test contains a single a II
|
||||
|
||||
2 tests, 0 failures
|
||||
|
||||
Pre- and Post-test file hooks
|
||||
=============================
|
||||
|
||||
To run some code before executing a test file or after executing it, the
|
||||
functions `setup_file` and `teardown_file` can be used.
|
||||
|
||||
The last example could be refactored to only create the tmp directory once:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup_file() {
|
||||
export DIR="./tmp"
|
||||
export FILE="${DIR}/test"
|
||||
mkdir "${DIR}"
|
||||
}
|
||||
|
||||
teardown_file() {
|
||||
rm -rf "${DIR}"
|
||||
}
|
||||
|
||||
setup() {
|
||||
echo 'a' >> "${FILE}"
|
||||
}
|
||||
|
||||
teardown() {
|
||||
rm "${FILE}"
|
||||
}
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains "${FILE}" '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains "${FILE}" '^a$'
|
||||
}
|
||||
|
||||
Multiple files
|
||||
==============
|
||||
|
||||
With `bats`, a file is a test suite. If you have multiple `bats` files in a
|
||||
directory and you provide the directory in the `bats` command line, `bats`
|
||||
will execute all the test suites.
|
||||
|
||||
Example: `bats .`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats .
|
||||
./first.bats
|
||||
✓ can run our script
|
||||
✗ second test
|
||||
(in test file ./first.bats, line 27)
|
||||
`false' failed
|
||||
./second.bats
|
||||
✓ multi file
|
||||
./test.bats
|
||||
✓ test contains a single a I
|
||||
✓ test contains a single a II
|
||||
|
||||
5 tests, 1 failure
|
||||
|
||||
Pre- and Post-suite hooks
|
||||
=========================
|
||||
|
||||
If you want to execute the same function before each test suite or after
|
||||
each test suite, create a file named `setup_suite.bash`. In this file,
|
||||
create a function named `setup_suite()` and another named `teardown_suite()`.
|
||||
|
||||
Exporting the test results
|
||||
==========================
|
||||
|
||||
Test results can be exported using the JUnit XML format. This can then be
|
||||
used in other tools and merged with other JUnit XML formats to generate a final
|
||||
test report.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats . -F junit
|
||||
|
||||
This will produce the following XML content on stdout:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<testsuites time="0.048">
|
||||
<testsuite name="./first.bats" tests="2" failures="1" errors="0" skipped="0" time="0.025" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./first.bats" name="can run our script" time="0.013" />
|
||||
<testcase classname="./first.bats" name="second test" time="0.012">
|
||||
<failure type="failure">(in test file ./first.bats, line 27)
|
||||
`false' failed</failure>
|
||||
</testcase>
|
||||
|
||||
</testsuite>
|
||||
<testsuite name="./second.bats" tests="1" failures="0" errors="0" skipped="0" time="0.008" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./second.bats" name="multi file" time="0.008" />
|
||||
|
||||
</testsuite>
|
||||
<testsuite name="./test.bats" tests="2" failures="0" errors="0" skipped="0" time="0.015" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./test.bats" name="test contains a single a I" time="0.008" />
|
||||
<testcase classname="./test.bats" name="test contains a single a II" time="0.007" />
|
||||
|
||||
</testsuite>
|
||||
</testsuites>
|
||||
|
||||
Going further
|
||||
=============
|
||||
|
||||
`bats` scripts can be checked with shellcheck for common mistakes.
|
||||
|
||||
The `bats-assert` add-on provides many helper functions to perform
|
||||
assertions with a more readable syntax than the shell's built-in syntax.
|
||||
|
||||
See https://github.com/bats-core/bats-assert
|
||||
|
||||
The `bats-file` add-on provides helper functions to check for files. See
|
||||
https://github.com/bats-core/bats-file/
|
||||
|
||||
You can find a list of projects using `bats` on this page:
|
||||
https://github.com/bats-core/bats-core/wiki/Projects-Using-Bats
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
==============================
|
||||
Belden CoreOS Testing Manual
|
||||
==============================
|
||||
|
||||
This manual is a work on progress on how to test and how to write test for
|
||||
CoreOS or CoreOS based distribution.
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
bats
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit d7b7b6fb6c7c5545e718e44f38853d1718ce5446
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit e3581b11d30d91d0363acb48a6aee47043b7e0bc
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 09d2f9391813674627ec53cb222da6c7a51221e6
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 8bb16533532b6abc2eded7d9961ab2a108fd7a5b
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 3d12b2788a45d86efcb1ad3e01f209558c54795c
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit bae3658ac0bc1c9adac7a882439cabb385cae720
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit cb2bc17e96552cdfc141d27bd9f4dbd95a872846
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 1b5405955c7c2579ed1f52522e2e177d0281fa33
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
# UEFI Secure boot configuration
|
||||
# ==============================================================================
|
||||
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR ??= "${RECIPE_SYSROOT_NATIVE}/${datadir}/keys"
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR ??= "${TOPDIR}/keys"
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
|
||||
|
||||
# UEFI Secure boot helpers
|
||||
|
|
@ -16,12 +16,12 @@ HOSTTOOLS += "sbsign"
|
|||
|
||||
# Ensure that the public keys are always deployed to the deploy directory
|
||||
# before running wic
|
||||
do_image_wic[depends] += "cos-certificates-and-keys-native:do_deploy"
|
||||
do_image_wic[depends] += "efi-secureboot-keys:do_deploy"
|
||||
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
|
||||
def get_coreos_secureboot_efi_boot_files(d):
|
||||
"""
|
||||
Return the list of pubkey file inside deploy if
|
||||
Return the list of pubkey file inside deploy if
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR is set or an empty string
|
||||
otherwise
|
||||
"""
|
||||
|
|
@ -31,4 +31,25 @@ def get_coreos_secureboot_efi_boot_files(d):
|
|||
|
||||
IMAGE_EFI_BOOT_FILES:append = " ${@get_coreos_secureboot_efi_boot_files(d)}"
|
||||
|
||||
def get_coreos_secureboot_keydir_hash(d):
|
||||
"""
|
||||
Generate a space separate list, with a value for each file inside of
|
||||
keydir. Fromat: <filename>:md5:<md5sum>
|
||||
"""
|
||||
import hashlib
|
||||
|
||||
keydir = d.getVar('COREOS_EFI_SECUREBOOT_KEYDIR')
|
||||
value = ""
|
||||
|
||||
for filepath in os.listdir(keydir):
|
||||
if os.path.isfile(filepath):
|
||||
md5 = bb.utils.md5_file(filepath)
|
||||
value += f"{filepath}:md5:{md5} "
|
||||
|
||||
return value
|
||||
|
||||
# The build system should detect if someone change one of the key inside
|
||||
# COREOS_EFI_SECUREBOOT_KEYDIR and rebuild all the recipes and artifacts that
|
||||
# depends on this directory
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR_HASH = "${@get_coreos_secureboot_keydir_hash(d)}"
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR[vardeps] += "COREOS_EFI_SECUREBOOT_KEYDIR_HASH"
|
||||
|
|
|
|||
|
|
@ -1,26 +0,0 @@
|
|||
|
||||
SWUPDATE_IMAGES += "MLO"
|
||||
SWUPDATE_IMAGES += "u-boot-beaglebone"
|
||||
SWUPDATE_IMAGES_FSTYPES[MLO] = ""
|
||||
SWUPDATE_IMAGES_FSTYPES[u-boot-beaglebone] = ".img"
|
||||
|
||||
COREOS_SWUPDATE_EXTENDS_FOR:append = "beaglebone"
|
||||
|
||||
def coreos_swupdate_extends_images_for_beaglebone(d,s):
|
||||
mlo = {
|
||||
"filename" : "MLO",
|
||||
"installed-directly" : "true",
|
||||
"device" : "/dev/disk/by-partlabel/mlo",
|
||||
"type" : "raw",
|
||||
"sha256" : swupdate_get_sha256(d, s, "MLO"),
|
||||
}
|
||||
|
||||
uboot = {
|
||||
"filename" : "u-boot-beaglebone.img",
|
||||
"installed-directly" : "true",
|
||||
"device" : "/dev/disk/by-partlabel/uboot",
|
||||
"type" : "raw",
|
||||
"sha256" : swupdate_get_sha256(d, s, "u-boot-beaglebone.img"),
|
||||
}
|
||||
|
||||
return [mlo, uboot]
|
||||
|
|
@ -11,8 +11,7 @@ include conf/machine/include/arm/armv7a/tune-cortexa8.inc
|
|||
|
||||
IMAGE_FSTYPES += "wic wic.xz wic.bmap"
|
||||
WKS_FILE ?= "beaglebone-sdcard.wks.in"
|
||||
COREOS_INSTALLER_WKS_FILE ?= "beaglebone-sdcard-installer.wks"
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image"
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
|
||||
do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot gptfdisk-native:do_populate_sysroot virtual/bootloader:do_deploy"
|
||||
do_image_wic[recrdeptask] += "do_bootimg"
|
||||
|
||||
|
|
@ -21,10 +20,10 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
|
|||
APPEND:append = " console=ttyS0,115200"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_VERSION_linux-yocto ?= "5.15%"
|
||||
|
||||
KERNEL_IMAGETYPE = "zImage"
|
||||
DTB_FILES = "ti/omap/am335x-bone.dtb ti/omap/am335x-boneblack.dtb ti/omap/am335x-bonegreen.dtb"
|
||||
KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
|
||||
KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
|
||||
|
|
@ -37,6 +36,9 @@ UBOOT_LOADADDRESS = "0x80008000"
|
|||
|
||||
MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
|
||||
|
||||
IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY}"
|
||||
IMAGE_EFI_BOOT_FILES ?= "${KERNEL_DEVICETREE}"
|
||||
|
||||
# support runqemu
|
||||
EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
|
||||
IMAGE_CLASSES += "qemuboot"
|
||||
|
|
@ -57,7 +59,12 @@ QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port
|
|||
# No watchdog available yet
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
|
||||
COREOS_IMAGE_SWUPDATE_EXTRACLASSES += "coreos-image-swupdate-beaglebone"
|
||||
# MBR disk can't select the root device by partition label as MBR doesn't have
|
||||
# a partition label. Using filesystem label only work with an initramfs and we
|
||||
# don't support it yet.
|
||||
COREOS_PLATFORM0_ROOT ?= "/dev/mmcblk0p3"
|
||||
COREOS_PLATFORM1_ROOT ?= "/dev/mmcblk0p4"
|
||||
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
require conf/machine/include/coreos-generic-features/legacy-mbr-disk.inc
|
||||
require conf/machine/include/coreos-generic-features/emmc.inc
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: eagle40-03
|
||||
#@DESCRIPTION: Machine support for EAGLE40-03
|
||||
#
|
||||
|
||||
require include/coreos-generic-arch/x64.inc
|
||||
|
||||
MACHINE_FEATURES += "pci usbhost x86 serial efi"
|
||||
|
||||
# Kernel configuration
|
||||
# ******************************************************************************
|
||||
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
|
||||
KERNEL_IMAGETYPE = "bzImage"
|
||||
|
||||
# getty configuration
|
||||
# ******************************************************************************
|
||||
|
||||
SERIAL_CONSOLES = "115200;ttyS0"
|
||||
SERIAL_CONSOLES_CHECK = "ttyS0"
|
||||
APPEND += "console=ttyS0,115200"
|
||||
|
||||
# Image generation
|
||||
# ******************************************************************************
|
||||
|
||||
# Ensure that both flash-image.bin and boot.scr are generated as they are needed
|
||||
# for a wic image
|
||||
WKS_FILE = "generic-uefi.wks.in"
|
||||
COREOS_INSTALLER_WKS_FILE ?= "generic-uefi-usb-installer.wks"
|
||||
IMAGE_FSTYPES += "wic.xz wic.bmap"
|
||||
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules"
|
||||
|
||||
# No watchdog available yet
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
@ -4,3 +4,11 @@
|
|||
MACHINE_FEATURES:append = " efi"
|
||||
|
||||
do_image_wic[depends] += "efibootguard-native:do_populate_sysroot efibootguard:do_deploy"
|
||||
|
||||
# Variable used in WKS file
|
||||
|
||||
WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --align 1024 --part-type=EF00'
|
||||
WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label platform0 --align 1024'
|
||||
WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label platform1 --align 1024'
|
||||
WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label boot0 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label boot1 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
# This configuration file should be included for all hardware that has an
|
||||
# integrated emmc
|
||||
|
||||
MACHINE_FEATURES += "emmc"
|
||||
|
||||
# Generate a SWU image to flash the emmc
|
||||
do_image[depends] += "coreos-emmc-flasher-${MACHINE}:do_swuimage"
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
|
||||
# MBR disk are still supported by CoreOS, but only for legacy product
|
||||
# This ensure that efibootguard / swupdate work with MBR disk
|
||||
|
||||
# Do not include this file in a machine configuration if the machine support
|
||||
# a GPT disk instead
|
||||
COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ?= "/dev/disk/by-label"
|
||||
|
||||
# MBR can't disk can't use partition label, but may use filesystem label
|
||||
# This will only work with an initramfs. If no initramfs is used, this will
|
||||
# have to be set to the right disk device inside the machine configuration
|
||||
# like that COREOS_PLATFORMx_ROOT = "/dev/mmcblk<DISK>p<PART>"
|
||||
COREOS_PLATFORM0_ROOT ?= "LABEL=platform0"
|
||||
COREOS_PLATFORM1_ROOT ?= "LABEL=platform1"
|
||||
|
||||
# MBR disk can't use --part-type but can use system-id
|
||||
WKS_PART_EFI ?= 'part --source efibootguard-efi --label efi --system-id 0xef'
|
||||
WKS_PART_EFIBOOTGUARD_A ?= 'part --source efibootguard-boot --label boot0 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ?= 'part --source efibootguard-boot --label boot1 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# Variables used in WKS file
|
||||
WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --part-type=EF00'
|
||||
WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
|
||||
WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label rootfs0'
|
||||
WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label rootfs1'
|
||||
WKS_PART_USERDATA ??= 'part /usr/local/data --fstype=btrfs --label userdata'
|
||||
|
||||
PART_EFI_SIZE ??= '64M'
|
||||
PART_ROOT_SIZE ??= '1G'
|
||||
PART_EFIBG_SIZE ??= '128M'
|
||||
PART_USERDATA_SIZE ??= '1G'
|
||||
|
||||
# Variables used in SFDISK file
|
||||
SFDISK_PART_EFI ??= 'type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, name="efi"'
|
||||
SFDISK_PART_EFIBOOTGUARD_A ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg0"'
|
||||
SFDISK_PART_EFIBOOTGUARD_B ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg1"'
|
||||
SFDISK_PART_ROOT_A ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs0"'
|
||||
SFDISK_PART_ROOT_B ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs1"'
|
||||
SFDISK_PART_USERDATA ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="userdata"'
|
||||
|
|
@ -6,12 +6,12 @@ MACHINE_FEATURES += "wifi efi"
|
|||
# Add an override that work for all pc image
|
||||
MACHINEOVERRIDES =. "vm:"
|
||||
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_VERSION_linux-yocto ?= "5.15%"
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
|
||||
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
|
||||
|
||||
IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk wic.vhdx"
|
||||
IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk"
|
||||
|
||||
WKS_FILE ?= "generic-uefi.wks.in"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot"
|
||||
|
|
@ -22,4 +22,3 @@ do_image_wic[recrdeptask] += "do_bootimg"
|
|||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR = "1"
|
||||
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: qemu-generic-arm64
|
||||
#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
|
||||
#have working firmware and boot via EFI.
|
||||
|
||||
require conf/machine/qemu-generic-arm64.conf
|
||||
MACHINEOVERRIDES =. "qemu-generic-arm64:"
|
||||
|
||||
COREOS_IMAGE_GENERATE_INSTALLER = "0"
|
||||
|
||||
WKS_FILE = "qemu-efi-coreos-generic.wks.in"
|
||||
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
@ -7,6 +7,3 @@ require include/coreos-generic-machine/vm.inc
|
|||
|
||||
SERIAL_CONSOLES_CHECK = "ttyS0"
|
||||
QB_SYSTEM_NAME = "qemu-system-x86_64"
|
||||
|
||||
# Currently we don't support the watchdog
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
COMPATIBLE_MACHINE = "beaglebone"
|
||||
|
||||
require coreos-emmc-flasher.inc
|
||||
require coreos-emmc-flasher-uboot.inc
|
||||
|
||||
SWUPDATE_IMAGES += "MLO"
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
software =
|
||||
{
|
||||
version = "@@DISTRO_VERSION@@";
|
||||
@@MACHINE@@ = {
|
||||
hardware-compatibility: ["1.0"];
|
||||
factory = {
|
||||
emmc = {
|
||||
partitions: (
|
||||
{
|
||||
type = "diskpart";
|
||||
device = "/dev/mmcblk1";
|
||||
properties: {
|
||||
labeltype = "dos";
|
||||
partition-1 = [ "size=32M", "start=133120", "name=efi", "type=0xef", "fstype=fat16"];
|
||||
};
|
||||
}
|
||||
);
|
||||
images: (
|
||||
{
|
||||
filename = "MLO";
|
||||
device = "/dev/mmcblk1";
|
||||
offset = "128K";
|
||||
sha256 = "$swupdate_get_sha256(MLO)";
|
||||
},
|
||||
{
|
||||
filename = "u-boot-beaglebone.img";
|
||||
device = "/dev/mmcblk1";
|
||||
offset = "384K";
|
||||
sha256 = "$swupdate_get_sha256(u-boot-beaglebone.img)";
|
||||
|
||||
}
|
||||
);
|
||||
files: (
|
||||
{
|
||||
filename = "efibootguardarm.efi";
|
||||
path = "/EFI/BOOT/bootarm.efi";
|
||||
device = "/dev/mmcblk1p1";
|
||||
filesystem = "vfat";
|
||||
sha256 = "$swupdate_get_sha256(efibootguardarm.efi)";
|
||||
properties: {
|
||||
create-destination = "true";
|
||||
}
|
||||
}
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# Machine that use u-boot can include this file after
|
||||
# coreo-swupdate-flasher.inc
|
||||
|
||||
# Add support to flash u-boot
|
||||
IMAGE_DEPENDS += "virtual/bootloader"
|
||||
|
||||
UBOOT_SUFFIX ??= "img"
|
||||
SWUPDATE_IMAGES += "u-boot"
|
||||
SWUPDATE_IMAGES_FSTYPES[u-boot] = ".${UBOOT_SUFFIX}"
|
||||
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
|
||||
DESCRIPTION = "SWU Image generation to flash the internal emmc"
|
||||
SECTION = "bootloaders"
|
||||
LICENSE = "CLOSED"
|
||||
PR = "r1"
|
||||
|
||||
SRC_URI = " \
|
||||
file://sw-description \
|
||||
"
|
||||
|
||||
# efibootguard
|
||||
# ==============================================================================
|
||||
# efibootguard support is not machine depends so it can be done here
|
||||
|
||||
require conf/image-uefi.conf
|
||||
|
||||
# The efibootguard binary has to be embedded into the image. swupdate will check
|
||||
# that the binary exist
|
||||
IMAGE_DEPENDS += "efibootguard"
|
||||
SWUPDATE_IMAGES += "efibootguard${EFI_ARCH}"
|
||||
|
||||
# Override or variable are not supported in var[flag] statement, but having more
|
||||
# flags than necessary doesn't do any arm
|
||||
SWUPDATE_IMAGES_FSTYPES[efibootguardx64] = ".efi"
|
||||
SWUPDATE_IMAGES_FSTYPES[efibootguardaa64] = ".efi"
|
||||
SWUPDATE_IMAGES_FSTYPES[efibootguardarm] = ".efi"
|
||||
|
||||
# Image generated should be named coreos-swupdater-flasher-${MACHINE}
|
||||
# and not the default coreos-swupdate-flasher-${MACHINE}-${MACHINE}
|
||||
IMAGE_BASENAME ?= "coreos-emmc-flasher"
|
||||
inherit swupdate
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
SUMMARY = "A recipe to deploy UEFI public keys update files"
|
||||
LICENSE = "CLOSED"
|
||||
|
||||
|
||||
INHIBIT_DEFAULT_DEPS = "1"
|
||||
inherit nopackages
|
||||
|
||||
inherit deploy
|
||||
inherit coreos-efi-secureboot
|
||||
|
||||
# Public key needed by firmware very depending on the implementation
|
||||
# So we copy all type of public key (*.auth, *.esl, *.crt, *der)
|
||||
addtask deploy after do_compile
|
||||
do_deploy() {
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.auth ${DEPLOYDIR}/KEK.auth
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.auth ${DEPLOYDIR}/db.auth
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.auth ${DEPLOYDIR}/PK.auth
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.esl ${DEPLOYDIR}/KEK.esl
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.esl ${DEPLOYDIR}/db.esl
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.esl ${DEPLOYDIR}/PK.esl
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.crt ${DEPLOYDIR}/KEK.crt
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.crt ${DEPLOYDIR}/db.crt
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.crt ${DEPLOYDIR}/PK.crt
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.der ${DEPLOYDIR}/KEK.der
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.der ${DEPLOYDIR}/db.der
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.der ${DEPLOYDIR}/PK.der
|
||||
|
||||
# !SECURITY WARNING!
|
||||
# .key file are not copied to DEPLOYDIR, as they contains the PRIVATE keys
|
||||
}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Add signature support
|
||||
|
||||
inherit coreos-efi-sbsign
|
||||
require conf/image-uefi.conf
|
||||
|
||||
do_deploy:append() {
|
||||
|
||||
if [ -f "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi" ]; then
|
||||
coreos_efi_secureboot_sign_app "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi"
|
||||
fi
|
||||
}
|
||||
|
|
@ -1,23 +1,12 @@
|
|||
# Ensure that file are found event when this file is included in another layer
|
||||
# ==============================================================================
|
||||
FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
|
||||
|
||||
# U-Boot CoreOS Distro Settings
|
||||
# ==============================================================================
|
||||
|
||||
# Enable more debug option when debug-tweaks is enabled
|
||||
SRC_URI += " \
|
||||
${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
|
||||
"
|
||||
|
||||
inherit coreos-efi-secureboot
|
||||
|
||||
# Make sure UEFI and secure boot is enabled for every u-boot build
|
||||
SRC_URI += " \
|
||||
file://uefi.cfg \
|
||||
file://uefi-secureboot.cfg \
|
||||
"
|
||||
|
||||
DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native"
|
||||
|
||||
# Generate a ubootefi.var file inside the build directory
|
||||
#
|
||||
# This file can be directly linked inside the u-boot binary to provide
|
||||
|
|
@ -26,7 +15,6 @@ SRC_URI += " \
|
|||
#
|
||||
# The efivar.py is taken from u-boot-tools recipes, so that we are sure that he
|
||||
# is found and don't depend on the u-boot version being used
|
||||
DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native cos-certificates-and-keys-native"
|
||||
addtask uboot_generate_efivar after do_configure before do_compile
|
||||
do_uboot_generate_efivar() {
|
||||
# Settings OPENSSL_MODULES is needed, otherwise efivar.py fail with
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Ensure that file are found event when this file is included in another layer
|
||||
# ==============================================================================
|
||||
FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
|
||||
|
||||
# Main include file for u-boot to ensure CoreOS compatibility
|
||||
# ==============================================================================
|
||||
|
||||
SRC_URI += " \
|
||||
${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
|
||||
"
|
||||
|
||||
require u-boot-coreos-efi.inc
|
||||
|
|
@ -4,6 +4,4 @@
|
|||
|
||||
do_install:append() {
|
||||
install -m 0755 ${S}/tools/efivar.py ${D}${bindir}/uboot-efivar
|
||||
}
|
||||
|
||||
FILES:${PN} += "${bindir}/uboot-efivar"
|
||||
}
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
|
||||
require u-boot-coreos.inc
|
||||
|
|
@ -4,3 +4,5 @@ require recipes-bsp/u-boot/u-boot.inc
|
|||
SRCREV = "4debc57a3da6c3f4d3f89a637e99206f4cea0a96"
|
||||
DEPENDS += "bc-native dtc-native python3-setuptools-native"
|
||||
LIC_FILES_CHKSUM = "file://Licenses/README;md5=2ca5f2c35c8cc335f0a19756634782f1"
|
||||
|
||||
require u-boot-coreos.inc
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
label: gpt
|
||||
device: /dev/mmcblk1
|
||||
unit: sectors
|
||||
first-lba: 34
|
||||
last-lba: 7471070
|
||||
sector-size: 512
|
||||
|
||||
# EBBR 2.1.0 section 4.1.1 mandate the use of an unused type UUID and to set
|
||||
# the RequiredPartition label for part of the firmware stored in the main disk
|
||||
# https://arm-software.github.io/ebbr/#section-gpt-parts
|
||||
# next two type were generated
|
||||
/dev/mmcblk1p1 : start= 256, size= 512, type=4DA6E9DA-C803-4BE4-BAC4-8192717C5EB0, name="mlo", attrs="RequiredPartition"
|
||||
/dev/mmcblk1p2 : start= 768, size= 8192, type=5B97345D-B7A1-47D3-A491-ED40F4841639, name="uboot", attrs="RequiredPartition"
|
||||
|
||||
/dev/mmcblk1p3 : size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
|
||||
/dev/mmcblk1p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
|
||||
/dev/mmcblk1p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
|
||||
/dev/mmcblk1p6 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
|
||||
/dev/mmcblk1p7 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
label: gpt
|
||||
device: /dev/mmcblk2
|
||||
unit: sectors
|
||||
first-lba: 34
|
||||
last-lba: 7471070
|
||||
sector-size: 512
|
||||
|
||||
/dev/mmcblk2p1 : start= 256, size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
|
||||
/dev/mmcblk2p2 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
|
||||
/dev/mmcblk2p3 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}
|
||||
/dev/mmcblk2p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
|
||||
/dev/mmcblk2p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
|
||||
/dev/mmcblk2p6 : size= ${PART_USERDATA_SIZE}, ${SFDISK_PART_USERDATA}
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/coreos-installer-config:"
|
||||
|
||||
SRC_URI:append:beaglebone = " file://beaglebone_1.0.sfdisk"
|
||||
SRC_URI:append:eagle40-03 = " file://eagle40-03_1.0.sfdisk"
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
CONFIG_F71808E_WDT=y
|
||||
CONFIG_WATCHDOG_SYSFS=y
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
CONFIG_HYPERVISOR_GUEST=y
|
||||
CONFIG_PARAVIRT=y
|
||||
CONFIG_PARAVIRT_SPINLOCKS=y
|
||||
CONFIG_CONNECTOR=y
|
||||
CONFIG_SCSI_FC_ATTRS=y
|
||||
CONFIG_HYPERV=y
|
||||
CONFIG_HYPERV_UTILS=y
|
||||
CONFIG_HYPERV_BALLOON=y
|
||||
CONFIG_HYPERV_STORAGE=y
|
||||
CONFIG_HYPERV_NET=y
|
||||
CONFIG_HYPERV_KEYBOARD=y
|
||||
CONFIG_FB_HYPERV=y
|
||||
CONFIG_HID_HYPERV_MOUSE=y
|
||||
CONFIG_PCI_HYPERV=y
|
||||
CONFIG_VSOCKETS=y
|
||||
CONFIG_HYPERV_VSOCKETS=y
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
|
||||
inherit coreos-efi-sbsign
|
||||
require conf/image-uefi.conf
|
||||
|
||||
# Ensure EFI STUB is enabled
|
||||
KERNEL_FEATURES:append = " cfg/efi.scc cfg/efi-ext.scc"
|
||||
|
||||
# By default we use a Unified Kernel Image that contain the kernel, the
|
||||
# kernel command line and some device tree, so we don't need to sign the output
|
||||
# of the kernel recipes
|
||||
COREOS_KERNEL_EFI_SIGNED ??= "0"
|
||||
|
||||
# Extend the kernel_do_deploy function from kernel.bbclass to sign the kernel
|
||||
kernel_do_deploy:append() {
|
||||
if [ "${COREOS_KERNEL_EFI_SIGNED}" == "1" ]; then
|
||||
deployDir="${DEPLOYDIR}"
|
||||
for imageType in ${KERNEL_IMAGETYPES} ; do
|
||||
baseName="$imageType-${KERNEL_IMAGE_NAME}"
|
||||
coreos_efi_secureboot_sign_app "$deployDir/$baseName${KERNEL_IMAGE_BIN_EXT}"
|
||||
done
|
||||
fi
|
||||
}
|
||||
|
||||
|
|
@ -1,20 +1,13 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
|
||||
KMACHINE:vm-x64 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
|
||||
|
||||
# Enable some kernel features related to virtualiuzation
|
||||
KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
|
||||
SRC_URI:append:vm-x64 = " file://hyperv.cfg"
|
||||
|
||||
KMACHINE:eagle40-03 ?= "common-pc-64"
|
||||
KBRANCH:eagle40-03 = "v5.15/standard/base"
|
||||
SRCREV_machine:eagle40-03 ?= "3baf1c5c0e6084b3f4a1d2d805168d657f872e60"
|
||||
COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
|
||||
LINUX_VERSION:eagle40-03 = "5.15.134"
|
||||
|
||||
|
||||
KBRANCH:beaglebone = "v5.15/standard/beaglebone"
|
||||
KMACHINE:beaglebone ?= "beaglebone"
|
||||
SRCREV_machine:beaglebone ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"
|
||||
COMPATIBLE_MACHINE:beaglebone = "beaglebone"
|
||||
LINUX_VERSION:beaglebone = "5.15.54"
|
||||
|
||||
require linux-yocto-coreos-efi.inc
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
|
||||
|
||||
KMACHINE:eagle40-03 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
|
||||
|
||||
KMACHINE:beaglebone ?= "beaglebone"
|
||||
COMPATIBLE_MACHINE:beaglebone = "beaglebone"
|
||||
|
||||
KMACHINE:vm-x64 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
|
||||
KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
|
||||
SRC_URI:append:vm-x64 = " file://hyperv.cfg"
|
||||
|
||||
SRC_URI += " file://eagle40-03.cfg"
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# short-description: Create SD card image for Beaglebone
|
||||
# long-description: Creates a partitioned SD card image for Beaglebone.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
|
||||
part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K
|
||||
part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M
|
||||
|
||||
# Let's define a 4MiB maximum size for the bootloader
|
||||
# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
|
||||
part --source bootimg-partition --part-type=EF00 --ondisk mmcblk0 --offset 8960S --fixed-size 125M
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,20 +1,11 @@
|
|||
# short-description: Create SD card image for Beaglebone
|
||||
# long-description: Creates a partitioned SD card image for Beaglebone.
|
||||
# Boot files are located in the first vfat partition.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K --part-name "mlo"
|
||||
part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M --part-name "uboot"
|
||||
|
||||
|
||||
# Let's define a 4MiB maximum size for the bootloader
|
||||
# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
|
||||
${WKS_PART_EFI} --ondisk mmcblk0 --offset 8960S --fixed-size 32M
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
|
||||
${WKS_PART_ROOT_A} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
|
||||
${WKS_PART_ROOT_B} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
|
||||
bootloader --ptable gpt
|
||||
part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --size 32M --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFI} --ondisk mmcblk0 --align 1024 --size 32M --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_A} --ondisk mmcblk0 --size 2G --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_B} --ondisk mmcblk0 --size 2G --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --align 1024 --size 128M --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --align 1024 --size 128M --extra-space 0 --overhead-factor 1
|
||||
bootloader --ptable msdos
|
||||
|
|
|
|||
|
|
@ -1,16 +0,0 @@
|
|||
# short-description: Create USB image for Eagle 40-03
|
||||
# long-description: Creates a partitioned USB image for Eagle 40-03.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
|
||||
part --offset 256S --source bootimg-partition --part-type=EF00 --ondisk mmcblk0
|
||||
part --fixed-size 3G --fstype=vfat --label=image
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,11 +1,10 @@
|
|||
# short-description: Create an EFI disk image for genericx86*
|
||||
# long-description: Creates a partitioned EFI disk image for genericx86* machines
|
||||
${WKS_PART_EFI} --ondisk sda --align 1024 --size 64M --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_A} --ondisk sda --size 2G --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_B} --ondisk sda --size 2G --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk sda --align 1024 --size 128M --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk sda --align 1024 --size 128M --extra-space 0 --overhead-factor 1
|
||||
|
||||
${WKS_PART_EFI} --align 1024 --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_A} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_B} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_A} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_B} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_USERDATA} --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
|
||||
|
||||
part swap --ondisk sda --size 44 --label swap1 --fstype=swap
|
||||
bootloader --ptable gpt
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
# short-description: Create an EFI disk image
|
||||
# long-description: Creates a partitioned EFI disk image that the user
|
||||
# can directly dd to boot media.
|
||||
|
||||
part --source efibootguard-efi --label efi --part-type=EF00 --use-uuid --offset 20480S --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part / --source rootfs --fstype=ext4 --label rootfs0 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --fstype=ext4 --label rootfs1 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_USERDATA} --use-uuid --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
|
||||
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
DESCRIPTION = "An image that includes k3s-agent"
|
||||
|
||||
require recipes-core/images/coreos-image-all-features.bb
|
||||
|
||||
IMAGE_INSTALL += "k3s-agent"
|
||||
|
||||
# To use this image, please add k3s to DISTRO_FEATURE inside your
|
||||
# local.conf config file.
|
||||
|
|
@ -2,12 +2,6 @@ SUMMARY = "A lighttpd container image"
|
|||
|
||||
inherit coreos-container-image
|
||||
|
||||
# Install systemd in the container
|
||||
IMAGE_FEATURES += "systemd"
|
||||
|
||||
# Allow to log using systemd without password
|
||||
IMAGE_FEATURES += "empty-root-password"
|
||||
|
||||
IMAGE_INSTALL:append = " \
|
||||
busybox \
|
||||
lighttpd \
|
||||
|
|
|
|||
|
|
@ -3,4 +3,5 @@ SUMMARY = "A lighttpd container package"
|
|||
inherit coreos-container-package
|
||||
|
||||
CONTAINER_IMAGE = "coreos-container-image-lighttpd"
|
||||
PODMAN_RUN_OPTIONS = "-p 80:80"
|
||||
PODMAN_RUN_OPTIONS = "-p 80:80 --entrypoint /usr/sbin/lighttpd"
|
||||
PODMAN_RUN_CMD = "-D -f /etc/lighttpd/lighttpd.conf"
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
#this file contains the necssary kernel adaption that k3s an containerd require
|
||||
#Reference
|
||||
#k3s config check: https://raw.githubusercontent.com/k3s-io/k3s/master/contrib/util/check-config.sh
|
||||
#container config check: https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh
|
||||
#these scripts are provided by moby and rancher
|
||||
CONFIG_OABI_COMPAT=n
|
||||
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
|
||||
CONFIG_SECCOMP_FILTER=y
|
||||
|
|
@ -1 +0,0 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Library to share code needed to install most available bats library
|
||||
|
||||
# Bats library are shell scripts, so they are arch independant
|
||||
inherit allarch
|
||||
|
||||
RDEPENDS:${PN} += "bats"
|
||||
|
||||
# Bats can find library in this folder by default
|
||||
BATS_LIB_PATH ?= "${libdir}/bats"
|
||||
|
||||
# By default the library will have the same name as the recipe
|
||||
BATS_INSTALL_DIR ?= "${BATS_LIB_PATH}/${PN}"
|
||||
FILES:${PN} += "${BATS_INSTALL_DIR}"
|
||||
|
||||
do_install() {
|
||||
install -d ${D}${BATS_INSTALL_DIR}
|
||||
cp -r ${S}/src ${D}${BATS_INSTALL_DIR}/
|
||||
install ${S}/load.bash ${D}${BATS_INSTALL_DIR}/
|
||||
}
|
||||
|
|
@ -9,30 +9,24 @@ NO_RECOMMENDATIONS = "1"
|
|||
# the host, thus we can't use linux-dummy has the default kernel provider.
|
||||
IMAGE_CONTAINER_NO_DUMMY = "1"
|
||||
|
||||
COREOS_CONTAINER_IMAGE_BASE_INSTALL = "\
|
||||
packagegroup-coreos-container \
|
||||
"
|
||||
|
||||
# Only install a reduced set of packages in a container. This correspond to
|
||||
# a subset of packagegroup-core-boot
|
||||
COREOS_CONTAINER_IMAGE_BASE_INSTALL = '\
|
||||
base-files \
|
||||
base-passwd \
|
||||
netbase \
|
||||
os-release \
|
||||
'
|
||||
|
||||
COREOS_CONTAINER_IMAGE_EXTRA_INSTALL ?= ""
|
||||
IMAGE_INSTALL ?= "${COREOS_CONTAINER_IMAGE_BASE_INSTALL} ${COREOS_CONTAINER_IMAGE_EXTRA_INSTALL}"
|
||||
|
||||
# OCI Parameters
|
||||
# ==============================================================================
|
||||
|
||||
OCI_IMAGE_ENTRYPOINT ?= "${@bb.utils.contains('IMAGE_FEATURES', 'systemd', '/usr/sbin/init', '/usr/bin/sh', d)}"
|
||||
|
||||
inherit image
|
||||
inherit image-oci
|
||||
|
||||
# Images features for containers
|
||||
# ==============================================================================
|
||||
|
||||
# Install systemd inside the container
|
||||
FEATURE_PACKAGES_systemd = "systemd"
|
||||
|
||||
|
||||
# Image Post processings
|
||||
# ==============================================================================
|
||||
inherit image
|
||||
inherit image-oci
|
||||
|
||||
IMAGE_CMD:oci:append() {
|
||||
# meta-virtualization default IMAGE_CMD doesn't create a symlink on kirkstone
|
||||
|
|
@ -47,27 +41,17 @@ IMAGE_CMD:oci:append() {
|
|||
|
||||
# Workaround /var/volatile for now
|
||||
# See layers/meta-virtualization/recipes-extended/images/container-base.bb
|
||||
ROOTFS_POSTPROCESS_COMMAND += "rootfs_fixup_var_volatile ; "
|
||||
ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('IMAGE_FEATURES', 'init-manager', '', 'rootfs_fixup_var_volatile ; ', d)}"
|
||||
rootfs_fixup_var_volatile () {
|
||||
install -m 1777 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/tmp
|
||||
install -m 755 -d ${IMAGE_ROOTFS}/${localstatedir}/volatile/log
|
||||
|
||||
# in rootfs-postcommands.bbclass, when using initscripts theses link
|
||||
# are created by running ${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
|
||||
# When the distro is configured to systemd, this is not done, so we need to
|
||||
# do it here manually (As systemd is not always included in the container)
|
||||
# When using systemd, systemd is responsible to link /var/{log,tmp} to /var/volutile/{log,tmp}
|
||||
# As container doesn't normally use systemd, we create the link by ourself here
|
||||
ln -sf ${localstatedir}/volatile/tmp ${IMAGE_ROOTFS}/${localstatedir}/tmp
|
||||
ln -sf ${localstatedir}/volatile/log ${IMAGE_ROOTFS}/${localstatedir}/log
|
||||
}
|
||||
|
||||
ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('IMAGE_FEATURES', 'systemd', 'rootfs_fixup_systemd ; ', '', d)}"
|
||||
rootfs_fixup_systemd () {
|
||||
# Mask systemd services that are not needed/doesn't work in a container
|
||||
# This ensure that the container doesn't boot in systemd emergency mode
|
||||
systemctl --root=${IMAGE_ROOTFS} mask systemd-remount-fs.service
|
||||
systemctl --root=${IMAGE_ROOTFS} mask var-volatile.mount
|
||||
}
|
||||
|
||||
# Add support for plugin classes like in coreos-image.bbclass
|
||||
COREOS_IMAGE_EXTRACLASSES ?= ""
|
||||
inherit ${COREOS_IMAGE_EXTRACLASSES}
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@
|
|||
# > COREOS_IMAGE_EXTRACLASSES += "coreos-image-ci"
|
||||
# in auto.conf (or local.conf)
|
||||
|
||||
inherit kernel-artifact-names
|
||||
|
||||
def get_coreos_ci_artifacts(d):
|
||||
artifacts = []
|
||||
|
|
@ -13,11 +12,11 @@ def get_coreos_ci_artifacts(d):
|
|||
|
||||
# Container handling
|
||||
# ==========================================================================
|
||||
|
||||
|
||||
if bb.utils.contains('IMAGE_FSTYPES', 'oci', True, False, d):
|
||||
|
||||
artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.rootfs-oci.tar')
|
||||
|
||||
|
||||
# Special case for container, we just need the OCI tarball
|
||||
return " ".join(artifacts)
|
||||
|
||||
|
|
@ -26,23 +25,13 @@ def get_coreos_ci_artifacts(d):
|
|||
|
||||
if bb.utils.contains('IMAGE_FSTYPES', 'wic.xz', True, False, d):
|
||||
artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.xz')
|
||||
|
||||
|
||||
if bb.utils.contains('IMAGE_FSTYPES', 'wic.bmap', True, False, d):
|
||||
artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.bmap')
|
||||
|
||||
# This is used for qemu-coreos-arm64
|
||||
if bb.utils.contains('IMAGE_FSTYPES', 'wic.qcow2', True, False, d):
|
||||
artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.wic.qcow2')
|
||||
|
||||
if d.getVar('COREOS_IMAGE_GENERATE_SWU') == '1':
|
||||
artifacts.append(d.getVar('IMAGE_LINK_NAME') + '.swu')
|
||||
|
||||
# CoreOS Installer
|
||||
# ==========================================================================
|
||||
|
||||
if d.getVar('COREOS_IMAGE_GENERATE_INSTALLER') == '1':
|
||||
artifacts.append('coreos-installer-' + d.getVar('MACHINE') + '.efi')
|
||||
|
||||
# Kernel
|
||||
# ==========================================================================
|
||||
|
||||
|
|
@ -51,7 +40,8 @@ def get_coreos_ci_artifacts(d):
|
|||
artifacts.append(kernel_imagetype + '-' + machine + kernel_image_bin_ext)
|
||||
|
||||
if d.getVar('COREOS_IMAGE_GENERATE_UKI') == '1':
|
||||
artifacts.append(d.getVar('COREOS_KERNEL_FILENAME'))
|
||||
artifacts.append(d.getVar('COREOS_KERNEL0_FILENAME'))
|
||||
artifacts.append(d.getVar('COREOS_KERNEL1_FILENAME'))
|
||||
|
||||
# Bootloaders
|
||||
# ==========================================================================
|
||||
|
|
@ -95,5 +85,5 @@ do_deploy_ci() {
|
|||
for file in ${COREOS_CI_DEPLOY_ARTIFACTS}; do
|
||||
echo $file >> $output
|
||||
done
|
||||
}
|
||||
}
|
||||
addtask deploy_ci after do_image before do_build
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
# Class used to generate image based on Belden CoreOS
|
||||
|
||||
export IMAGE_BASENAME = "${MLPREFIX}${PN}"
|
||||
IMAGE_NAME_SUFFIX ?= ""
|
||||
IMAGE_LINGUAS = ""
|
||||
|
||||
LICENSE = "MIT"
|
||||
|
||||
IMAGE_FSTYPES = "cpio.gz"
|
||||
|
||||
# Support for generating a SDCard or USB installer is optional
|
||||
COREOS_INSTALLER_WKS_FILE ??= ""
|
||||
WKS_FILE = "${COREOS_INSTALLER_WKS_FILE}"
|
||||
IMAGE_FSTYPES += "${@'wic.xz wic.bmap' if d.getVar('COREOS_INSTALLER_WKS_FILE') else ''}"
|
||||
IMAGE_BOOT_FILES = "${COREOS_KERNEL_FILENAME};EFI/BOOT/${EFI_BOOT_IMAGE}"
|
||||
|
||||
COREOS_IMAGE_GENERATE_UKI = "1"
|
||||
|
||||
# IMGDEPLOYDIR has to be used instead of DEPLOY_DIR_IMAGE here, because it will
|
||||
# run during image generation
|
||||
COREOS_UKI_PART_INITRAMFS = "${IMGDEPLOYDIR}/${IMAGE_BASENAME}-${MACHINE}.cpio.gz"
|
||||
COREOS_IMAGE_GENERATE_SWU = "0"
|
||||
|
||||
# Change generated UKI filename and reset the bundled command line to "APPEND"
|
||||
# to ensure that root is not set in the kernel command line
|
||||
COREOS_KERNEL_NAME ?= "coreos-installer-${MACHINE}"
|
||||
COREOS_KERNEL_CMDLINE ?= "${APPEND}"
|
||||
|
||||
inherit coreos-image
|
||||
|
||||
# Only install a reduced set of package and feature to keep image size small
|
||||
IMAGE_INSTALL = "packagegroup-coreos-boot coreos-installer coreos-installer-unattended util-linux-sfdisk util-linux-fdisk util-linux-cfdisk efibootguard efibootguard-tools"
|
||||
IMAGE_FEATURES = "debug-tweaks swupdate"
|
||||
NO_RECOMMENDATIONS = "1"
|
||||
|
||||
IMAGE_ROOTFS_SIZE = "8192"
|
||||
INITRAMFS_MAXSIZE = "976562"
|
||||
IMAGE_ROOTFS_EXTRA_SPACE = "0"
|
||||
|
||||
# Use the same restriction as initramfs-module-install
|
||||
COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
|
||||
|
|
@ -7,6 +7,9 @@
|
|||
# Swupdate image generation
|
||||
# ==============================================================================
|
||||
|
||||
# Machine using MBR override this value, see legacy-mbr-disk.inc
|
||||
COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ??= "/dev/disk/by-partlabel"
|
||||
|
||||
IMAGE_FSTYPES:append = " ext4.zst"
|
||||
python () {
|
||||
image = d.getVar('IMAGE_BASENAME')
|
||||
|
|
@ -16,64 +19,16 @@ python () {
|
|||
inherit swupdate-image
|
||||
|
||||
# Ensure than variable used in the sw-description files are watched for change
|
||||
do_swuimage[vardeps] += "COREOS_KERNEL_FILENAME EFIBOOTGUARD_TIMEOUT EFIDIR EFI_BOOT_IMAGE COREOS_EFIBOOTGUARD_FILENAME"
|
||||
do_swuimage[vardeps] += "COREOS_KERNEL0_FILENAME COREOS_KERNEL1_FILENAME EFIBOOTGUARD_TIMEOUT COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY APPEND"
|
||||
do_swuimage[deptask] += "do_bundle_uki"
|
||||
|
||||
COREOS_EFIBOOTGUARD_NAME ?= "efibootguard${EFI_ARCH}"
|
||||
COREOS_EFIBOOTGUARD_EXT ?= ".efi"
|
||||
COREOS_EFIBOOTGUARD_FILENAME = "${COREOS_EFIBOOTGUARD_NAME}${COREOS_EFIBOOTGUARD_EXT}"
|
||||
|
||||
SWUPDATE_IMAGES += "${COREOS_KERNEL_NAME} ${COREOS_EFIBOOTGUARD_NAME}"
|
||||
SWUPDATE_IMAGES += "${COREOS_KERNEL0_NAME} ${COREOS_KERNEL1_NAME}"
|
||||
|
||||
python () {
|
||||
kernel = d.getVar('COREOS_KERNEL_NAME')
|
||||
kernel0 = d.getVar('COREOS_KERNEL0_NAME')
|
||||
kernel1 = d.getVar('COREOS_KERNEL1_NAME')
|
||||
kernelext = d.getVar('COREOS_KERNEL_EXT')
|
||||
d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel, kernelext)
|
||||
|
||||
efibootguard = d.getVar('COREOS_EFIBOOTGUARD_NAME')
|
||||
efibootguardext = d.getVar('COREOS_EFIBOOTGUARD_EXT')
|
||||
d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", efibootguard, efibootguardext)
|
||||
d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel0, kernelext)
|
||||
d.setVarFlag("SWUPDATE_IMAGES_FSTYPES", kernel1, kernelext)
|
||||
}
|
||||
|
||||
FILESEXTRAPATHS:append := ":${COREOS_ROOT}/layers/meta-belden-coreos/files"
|
||||
|
||||
# Space seperated list of extension points
|
||||
COREOS_SWUPDATE_EXTENDS_FOR ??= ""
|
||||
|
||||
def coreos_swupdate_extends(d, s, key):
|
||||
"""
|
||||
Extends the swupdate for each extension points defined by COREOS_SWUPDATE_EXTENDS_FOR
|
||||
"""
|
||||
extends_for = d.getVar('COREOS_SWUPDATE_EXTENDS_FOR', True).replace("-", "_").split()
|
||||
|
||||
def kv_to_sw_description(kv):
|
||||
swdescr = ",{\n"
|
||||
for key, value in kv.items():
|
||||
swdescr += f'{key} = "{value}";\n'
|
||||
swdescr += "}\n"
|
||||
return swdescr
|
||||
|
||||
text = ""
|
||||
|
||||
# BSP and Distro can extends the swupdate by implementing some python
|
||||
# function that return a list of dictionary.
|
||||
for extension_point in extends_for:
|
||||
try:
|
||||
kv_list = globals()[f"coreos_swupdate_extends_{key}_for_{extension_point}"](d,s)
|
||||
except KeyError:
|
||||
# Don't fail if the extension is not implemented
|
||||
pass
|
||||
else:
|
||||
for kv in kv_list:
|
||||
text += kv_to_sw_description(kv)
|
||||
|
||||
return text
|
||||
|
||||
# Signature support
|
||||
inherit coreos-efi-secureboot
|
||||
SWUPDATE_SIGNING = "CMS"
|
||||
SWUPDATE_CMS_KEY = "${COREOS_EFI_SECUREBOOT_KEYDIR}/swupdate.key"
|
||||
SWUPDATE_CMS_CERT = "${COREOS_EFI_SECUREBOOT_KEYDIR}/swupdate.crt"
|
||||
|
||||
COREOS_IMAGE_SWUPDATE_EXTRACLASSES ?= ""
|
||||
inherit ${COREOS_IMAGE_SWUPDATE_EXTRACLASSES}
|
||||
|
|
|
|||
|
|
@ -10,29 +10,26 @@ inherit coreos-efi-sbsign
|
|||
# ==============================================================================
|
||||
|
||||
COREOS_KERNEL_EXT ??= ".efi"
|
||||
COREOS_KERNEL_NAME ??= "kernel-${MACHINE}"
|
||||
COREOS_KERNEL_FILENAME ??= "${COREOS_KERNEL_NAME}${COREOS_KERNEL_EXT}"
|
||||
COREOS_KERNEL ??= "${DEPLOY_DIR_IMAGE}/${COREOS_KERNEL_FILENAME}"
|
||||
COREOS_KERNEL0_NAME ??= "kernel0-${MACHINE}"
|
||||
COREOS_KERNEL1_NAME ??= "kernel1-${MACHINE}"
|
||||
COREOS_KERNEL0_FILENAME ??= "${COREOS_KERNEL0_NAME}${COREOS_KERNEL_EXT}"
|
||||
COREOS_KERNEL1_FILENAME ??= "${COREOS_KERNEL1_NAME}${COREOS_KERNEL_EXT}"
|
||||
|
||||
# Kernel command line
|
||||
# ==============================================================================
|
||||
|
||||
# AUTOLABEL will be replaced by the right PARTLABEL (rootfs0 or rootfs1) at
|
||||
# runtime in the efibootguard UKI stub
|
||||
COREOS_ROOTFS_ROOT ??= "PARTLABEL=AUTOLABEL"
|
||||
COREOS_KERNEL_CMDLINE ??= "root=${COREOS_ROOTFS_ROOT} ${APPEND} rootwait"
|
||||
|
||||
COREOS_UKI_PART_KERNEL_FILENAME ??= "${KERNEL_IMAGETYPE}-${MACHINE}${KERNEL_IMAGE_BIN_EXT}"
|
||||
COREOS_UKI_PART_KERNEL ??= "${DEPLOY_DIR_IMAGE}/${COREOS_UKI_PART_KERNEL_FILENAME}"
|
||||
COREOS_UKI_PART_STUB_FILENAME ??= "kernel-stub${EFI_ARCH}.efi"
|
||||
COREOS_UKI_PART_STUB ??= "${STAGING_LIBDIR}/efibootguard/${COREOS_UKI_PART_STUB_FILENAME}"
|
||||
COREOS_UKI_PART_INITRAMFS ??= ""
|
||||
APPEND += "rootwait "
|
||||
COREOS_PLATFORM0_ROOT ??= "PARTLABEL=platform0"
|
||||
COREOS_PLATFORM1_ROOT ??= "PARTLABEL=platform1"
|
||||
COREOS_KERNEL0_CMDLINE ??= "root=${COREOS_PLATFORM0_ROOT} ${APPEND}"
|
||||
COREOS_KERNEL1_CMDLINE ??= "root=${COREOS_PLATFORM0_ROOT} ${APPEND}"
|
||||
|
||||
# UKI Generation
|
||||
# ==============================================================================
|
||||
|
||||
do_image_uki() {
|
||||
do_bundle_uki() {
|
||||
deployDir="${DEPLOY_DIR_IMAGE}"
|
||||
kernel=${KERNEL_IMAGETYPE}-${MACHINE}${KERNEL_IMAGE_BIN_EXT}
|
||||
|
||||
# Create an array with device tree if any
|
||||
DTB_PARAMS=""
|
||||
|
|
@ -43,37 +40,26 @@ do_image_uki() {
|
|||
DTB_PARAMS="${DTB_PARAMS} --dtb=${deployDir}/${dtb}"
|
||||
done
|
||||
|
||||
echo "kernel: ${COREOS_UKI_PART_KERNEL_FILENAME}"
|
||||
echo "kernel: ${kernel}"
|
||||
echo "dtb: ${DTB_PARAMS}"
|
||||
echo "cmdline: ${COREOS_KERNEL_CMDLINE}"
|
||||
echo "initramfs: ${COREOS_UKI_PART_INITRAMFS}"
|
||||
|
||||
if [ ! -z "${COREOS_UKI_PART_INITRAMFS}" ]; then
|
||||
DTB_PARAMS="${DTB_PARAMS} --initrd=${COREOS_UKI_PART_INITRAMFS}"
|
||||
fi
|
||||
|
||||
echo "initramfs: ${INITRAMFS_PARAMS}"
|
||||
|
||||
bg_gen_unified_kernel \
|
||||
"${COREOS_UKI_PART_STUB}" \
|
||||
"${COREOS_UKI_PART_KERNEL}" \
|
||||
"${COREOS_KERNEL}" \
|
||||
--cmdline "${COREOS_KERNEL_CMDLINE}" \
|
||||
"${STAGING_LIBDIR}/efibootguard/kernel-stub${EFI_ARCH}.efi" \
|
||||
"${deployDir}/${kernel}" \
|
||||
"${deployDir}/${COREOS_KERNEL0_FILENAME}" \
|
||||
--cmdline "console=ttyS0,115200 root=${COREOS_PLATFORM0_ROOT} rootwait " \
|
||||
${DTB_PARAMS}
|
||||
|
||||
coreos_efi_secureboot_sign_app "${deployDir}/${COREOS_KERNEL_FILENAME}"
|
||||
bg_gen_unified_kernel \
|
||||
"${STAGING_LIBDIR}/efibootguard/kernel-stub${EFI_ARCH}.efi" \
|
||||
"${deployDir}/${kernel}" \
|
||||
"${deployDir}/${COREOS_KERNEL1_FILENAME}" \
|
||||
--cmdline "console=ttyS0,115200 root=${COREOS_PLATFORM1_ROOT} rootwait " \
|
||||
${DTB_PARAMS}
|
||||
|
||||
coreos_efi_secureboot_sign_app "${deployDir}/${COREOS_KERNEL0_FILENAME}"
|
||||
coreos_efi_secureboot_sign_app "${deployDir}/${COREOS_KERNEL1_FILENAME}"
|
||||
}
|
||||
|
||||
do_image_uki[depends] += "virtual/kernel:do_deploy efibootguard-native:do_populate_sysroot efibootguard:do_populate_sysroot"
|
||||
|
||||
|
||||
addtask image_uki after do_image before do_image_complete
|
||||
|
||||
# UKI image is normally embedded into a WIC image
|
||||
do_image_wic[recrdeptask] += "do_image_uki"
|
||||
|
||||
# UKI image is normally embedded into a SWU image
|
||||
do_image_swu[recrdeptask] += "${@'do_image_uki' if d.getVar('COREOS_IMAGE_GENERATE_SWU') == '1' else ''}"
|
||||
|
||||
# UKI image may embedded the rootfs as a cpio archive, in this case do_image_uki should run after do_image_cpio
|
||||
do_image_uki[recrdeptask] += "${@'do_image_cpio' if d.getVar('COREOS_UKI_PART_INITRAMFS') else ''}"
|
||||
do_bundle_uki[depends] += "virtual/kernel:do_deploy efibootguard-native:do_populate_sysroot efibootguard:do_populate_sysroot"
|
||||
addtask bundle_uki after do_rootfs before do_image
|
||||
|
|
|
|||
|
|
@ -24,7 +24,6 @@ FEATURE_PACKAGES_cockpit = "packagegroup-coreos-cockpit ${@get_feature_packages_
|
|||
# *-dev-tools FEATURES_PACKAGES for any image features
|
||||
FEATURE_PACKAGES_dev-tools = "${@get_feature_packages_with_suffix('dev-tools', d)}"
|
||||
|
||||
|
||||
def get_feature_packages_with_suffix(suffix, d):
|
||||
"""
|
||||
For each feature inside IMAGE_FEATURES, look if a FEATURE_PACKAGE variable
|
||||
|
|
@ -65,10 +64,17 @@ PACKAGE_EXCLUDE_COMPLEMENTARY:append = "${@bb.utils.contains_any('PACKAGE_INSTAL
|
|||
# IMAGE_FEATURES_CONFLICTS_foo = 'bar1 bar2'
|
||||
# An error exception would be raised if both image features foo and bar1(or bar2) are included
|
||||
|
||||
# packagegroup-core-boot will install the EFI_PROVIDER package if EFI is in Machine
|
||||
# feature. We use this variable to install more EFI related tools
|
||||
COREOS_IMAGE_EFI_PROVIDER_EXTRA = " \
|
||||
${@'efibootguard-tools' if d.getVar('EFI_PROVIDER') == 'efibootguard' else ''} \
|
||||
"
|
||||
|
||||
COREOS_IMAGE_BASE_INSTALL = "\
|
||||
packagegroup-coreos-boot \
|
||||
packagegroup-coreos-base \
|
||||
secure-storage \
|
||||
packagegroup-core-boot \
|
||||
packagegroup-base-extended \
|
||||
${@bb.utils.contains("MACHINE_FEATURES", "efi", "${COREOS_IMAGE_EFI_PROVIDER_EXTRA}", "", d)} \
|
||||
os-release \
|
||||
"
|
||||
|
||||
COREOS_IMAGE_EXTRA_INSTALL ?= ""
|
||||
|
|
@ -90,15 +96,9 @@ IMAGE_ROOTFS_EXTRA_SPACE:append = " ${@bb.utils.contains('DISTRO_FEATURES', 'sys
|
|||
# Unified kernel image and swupdate support
|
||||
# ==============================================================================
|
||||
|
||||
# The CoreOS image installer is disabled by default.
|
||||
COREOS_IMAGE_GENERATE_INSTALLER ?= "0"
|
||||
|
||||
# Support for Unified Kernel Image and Swupdate are optional.
|
||||
COREOS_IMAGE_GENERATE_UKI ?= "${@bb.utils.contains("COMBINED_FEATURES", "efi", "1", "0", d)}"
|
||||
COREOS_IMAGE_GENERATE_SWU ?= "${@"1" if "efi" in d.getVar('COMBINED_FEATURES') and "swupdate" in d.getVar("DISTRO_FEATURES") else "0"}"
|
||||
|
||||
# Generate the installer image if needed
|
||||
do_build[depends] += "${@'coreos-image-installer:do_build' if d.getVar('COREOS_IMAGE_GENERATE_INSTALLER') == '1' else ''}"
|
||||
# Support for Unified Kernel Image and Swupdate are optional
|
||||
COREOS_IMAGE_GENERATE_UKI ?= "1"
|
||||
COREOS_IMAGE_GENERATE_SWU ?= "1"
|
||||
|
||||
COREOS_IMAGE_EXTRACLASSES += "${@'coreos-image-uki' if d.getVar('COREOS_IMAGE_GENERATE_UKI') == '1' else ''}"
|
||||
COREOS_IMAGE_EXTRACLASSES += "${@'coreos-image-swupdate' if d.getVar('COREOS_IMAGE_GENERATE_SWU') == '1' else ''}"
|
||||
|
|
|
|||
|
|
@ -13,8 +13,6 @@ addhandler check_coreos_sanity_eventhandler
|
|||
check_coreos_sanity_eventhandler[eventmask] = "bb.event.SanityCheck"
|
||||
python check_coreos_sanity_eventhandler() {
|
||||
|
||||
import datetime
|
||||
|
||||
# Checks related to the distribution configuration files
|
||||
# ==========================================================================
|
||||
|
||||
|
|
@ -31,22 +29,13 @@ python check_coreos_sanity_eventhandler() {
|
|||
"systemd is not set as `INIT_MANAGER`. "
|
||||
"Using SystemD is mandatory on CoreOS based distribution"
|
||||
)
|
||||
|
||||
|
||||
if e.data.getVar("TCLIBC") != "glibc":
|
||||
bb.fatal(
|
||||
"glibc is not set as `TCLIBC`. "
|
||||
"Using glibc is mandatory on CoreOS based distribution"
|
||||
)
|
||||
|
||||
# Check if the timestamp for REPRODUCIBLE_TIMESTAMP_ROOTFS is still up to date
|
||||
first_of_year = datetime.datetime(datetime.date.today().year, 1, 1, tzinfo=datetime.timezone.utc)
|
||||
foy_ts = str(int(first_of_year.timestamp()))
|
||||
if e.data.getVar("REPRODUCIBLE_TIMESTAMP_ROOTFS") != foy_ts:
|
||||
bb.warn(
|
||||
"`REPRODUCIBLE_TIMESTAMP_ROOTFS` outdated!"
|
||||
"Set to current 01. january of the year."
|
||||
)
|
||||
|
||||
|
||||
# Checks related to the machine configuration files
|
||||
# ==========================================================================
|
||||
|
||||
|
|
@ -58,7 +47,7 @@ python check_coreos_sanity_eventhandler() {
|
|||
"CoreOS recommands to use compressed wic image, please add "
|
||||
"`wic.xz` to your machine `IMAGE_FSTYPES` variables"
|
||||
)
|
||||
|
||||
|
||||
if not "wic.bmap":
|
||||
bb.warn(
|
||||
"wic image should be flashed with bmaptools, but this require "
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue