meta-belden-bsp: add containers machine
This commit is contained in:
Samuel Dolt
parent
3f30c262d5
commit
2557c4030f
|
|
@ -23,6 +23,7 @@ same structures.
|
|||
|
||||
Quick Build <quick-build>
|
||||
Setting up a CoreOS based distro <using-coreos>
|
||||
Building and using a Container Image <using-container>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ Belden CoreOS Reference Manual
|
|||
|
||||
classes
|
||||
distro
|
||||
machines
|
||||
images
|
||||
features
|
||||
variables
|
||||
|
|
|
|||
|
|
@ -0,0 +1,76 @@
|
|||
********
|
||||
Machines
|
||||
********
|
||||
|
||||
The CoreOS build system provides several machines:
|
||||
|
||||
Generic Architecture
|
||||
====================
|
||||
|
||||
Some machines generate code that are generic over a wide range of architecture.
|
||||
|
||||
When this is the case, the machine name end with a CoreOS specific architecture
|
||||
suffix:
|
||||
|
||||
x64
|
||||
---
|
||||
|
||||
The x64 suffix is used for machine that generate code that can run on any modern
|
||||
AMD64 computer. This need at least a Core2 Duo processor.
|
||||
|
||||
arm32
|
||||
-----
|
||||
|
||||
The arm32 suffix is used to generate code that is compatible with any ARM
|
||||
processor that is compatible with the ARMv7a Architecture and both the NEON
|
||||
and VFPv3-D32 extension set.
|
||||
|
||||
arm64
|
||||
-----
|
||||
|
||||
The arm64 suffis is used to generate cade that is compatible with any ARM
|
||||
provessor that is compatible with the AArch64 architecture.
|
||||
|
||||
.. _ref-machine-vm:
|
||||
|
||||
Virtual Machines
|
||||
================
|
||||
|
||||
Virtual machines can be used to boot an image on any UEFI compatible virtual
|
||||
machine hypervisor. The build system generates a virtual machine disk in the
|
||||
`.vmdk` format by default.
|
||||
|
||||
The following virtual machines are available:
|
||||
|
||||
- vm-x64
|
||||
|
||||
The `vm` machine override can be used on all these machines.
|
||||
|
||||
.. hint::
|
||||
|
||||
When installing using the ISO file, UEFI secure boot should be desactived.
|
||||
After the installation, or when using the `.vmdk` file directly, it is
|
||||
recommanded to activate the UEFI Secure Boot on the (virtual) machine
|
||||
firmware.
|
||||
|
||||
Public key needed by the firmware are available on the EFI partition of the
|
||||
image.
|
||||
|
||||
|
||||
.. _ref-machine-container:
|
||||
|
||||
Containers
|
||||
==========
|
||||
|
||||
Container machine generate an OCI archive that can be imported on tools like
|
||||
Podman or Docker. The generate archive doesn't contain a kernel, neither an
|
||||
init system.
|
||||
|
||||
The following container machines are available:
|
||||
|
||||
- container-x64
|
||||
- container-arm32
|
||||
- container-arm64
|
||||
|
||||
The `container` machine override can be used on all these machines.
|
||||
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
************************************
|
||||
Building and Using a Container Image
|
||||
************************************
|
||||
|
||||
Building a container image based on CoreOS is really easy. You have to set
|
||||
the machine to either of the following value in the `local.conf` file:
|
||||
|
||||
- container-x64
|
||||
- container-arm64
|
||||
- container-arm32
|
||||
|
||||
.. hint::
|
||||
|
||||
The machine can also be overwriting from the shell using
|
||||
`MACHINE=<machine> bitbake`
|
||||
|
||||
Then you can generate any image by running:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
$ bitbake <image>
|
||||
|
||||
As an example, you can build the `coreos-image-minimal` as an OCI container
|
||||
for AMD64 machine with the following command:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
$ MACHINE=container-x64 bitbake core-image-minimal
|
||||
|
||||
|
||||
This will generate a container tarball in the tar.gz format.
|
||||
|
||||
If you are using `podman`, you can import the container with:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
$ cd $BUILDDIR/tmp/deploy/images/container-x64
|
||||
$ podman import coreos-image-container-container-x64.tar.bz2
|
||||
Getting image source signatures
|
||||
Copying blob 46c0b1c53d42 [--------------------------------------] 0.0b / 0.0b
|
||||
Copying config 051856498a done
|
||||
Writing manifest to image destination
|
||||
Storing signatures
|
||||
051856498a59e0ae6349492539efaf915a33dd73e7a54ce9683b0414d1481fae
|
||||
|
||||
Then you can use start any program included in the image with:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
$ podman run <PODMAN_ARGS> <IMAGE_ID> <COMMAND> <COMMAND_ARGS>
|
||||
|
||||
To run an interactive shell, you can use:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
$ podman run -i <IMAGE_ID> ash --i
|
||||
/ #
|
||||
|
||||
The `<IMAGE_ID>` should be copied from the output of `podman import`. In this
|
||||
exemple, it was
|
||||
`051856498a59e0ae6349492539efaf915a33dd73e7a54ce9683b0414d1481fae`.
|
||||
|
||||
You are now inside the container, try the following command:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
/ # cat /etc/os-release
|
||||
ID=belden-coreos
|
||||
NAME="Belden CoreOS"
|
||||
VERSION="0.0.1-feat/oci-image+75cf54e4b54b713d8ebeafddd122aeb615715ef9 (kirkstone)"
|
||||
VERSION_ID=0.0.1-feat/oci-image-75cf54e4b54b713d8ebeafddd122aeb615715ef9
|
||||
PRETTY_NAME="Belden CoreOS 0.0.1-feat/oci-image+75cf54e4b54b713d8ebeafddd122aeb615715ef9 (kirkstone)"
|
||||
DISTRO_CODENAME="kirkstone"
|
||||
|
||||
.. note::
|
||||
|
||||
Image generated using any container machines doesn't include the Linux
|
||||
kernel neither many system componant that are usually not used on a container
|
||||
like SystemD or udev. This is done inside the machine configuration by
|
||||
settings all the `VIRTUAL_RUNTIME_<component>` to an empty string.
|
||||
|
||||
Any of these system component can be added to the image if needed, by adding
|
||||
them by their real name (instead of using any `VIRTUAL_RUNTIME_` variables)
|
||||
in the `IMAGE_INSTALL` variables.
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
require include/coreos-generic-arch/arm32.inc
|
||||
require include/coreos-generic-machine/container.inc
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
require include/coreos-generic-arch/arm64.inc
|
||||
require include/coreos-generic-machine/container.inc
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
require include/coreos-generic-arch/x64.inc
|
||||
require include/coreos-generic-machine/container.inc
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Container will require a host with at least an Armv7 CPU with VFPv3 and Neon.
|
||||
DEFAULTTUNE ?= "armv7athf-neon"
|
||||
require conf/machine/include/arm/arch-armv7a.inc
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
DEFAULTTUNE ?= "aarch64"
|
||||
require conf/machine/include/arm/arch-arm64.inc
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
DEFAULTTUNE ?= "core2-64"
|
||||
require conf/machine/include/x86/tune-core2.inc
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
|
||||
IMAGE_FSTYPES += "container"
|
||||
|
||||
# Add an override that work for all container image
|
||||
MACHINEOVERRIDES =. "container:"
|
||||
|
||||
# Containers don't need a kernel
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
|
||||
|
||||
# Containers normaly don't need systemd or any of the VIRTUAL_RUNTIME.
|
||||
# One ways to remove it is to make a custome base image for container that don't
|
||||
# install any of the virtual runtime, the other ways is to use the same image
|
||||
# as for non-container machine and just set all the VIRTUAL_RUNTIME variables
|
||||
# to an empty string here:
|
||||
VIRTUAL-RUNTIME_dev_manager = ""
|
||||
VIRTUAL-RUNTIME_login_manager = ""
|
||||
VIRTUAL-RUNTIME_init_manager = ""
|
||||
VIRTUAL-RUNTIME_initscripts = ""
|
||||
VIRTUAL-RUNTIME_keymaps = ""
|
||||
|
|
@ -3,12 +3,15 @@ require conf/machine/include/x86/qemuboot-x86.inc
|
|||
|
||||
MACHINE_FEATURES += "wifi efi"
|
||||
|
||||
# Add an override that work for all pc image
|
||||
MACHINEOVERRIDES =. "vm:"
|
||||
|
||||
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 iso"
|
||||
IMAGE_FSTYPES += "ext4 wic wic.bmap wic.vmdk"
|
||||
|
||||
WKS_FILE ?= "generic-uefi.wks.in"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot"
|
||||
|
|
@ -2,10 +2,8 @@
|
|||
#@NAME: Generic x86_64
|
||||
#@DESCRIPTION: Machine configuration for generic x86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware.
|
||||
|
||||
DEFAULTTUNE ?= "core2-64"
|
||||
require conf/machine/include/x86/tune-core2.inc
|
||||
require conf/machine/include/pc-common.inc
|
||||
require include/coreos-generic-arch/x64.inc
|
||||
require include/coreos-generic-machine/vm.inc
|
||||
|
||||
SERIAL_CONSOLES_CHECK = "ttyS0"
|
||||
#For runqemu
|
||||
QB_SYSTEM_NAME = "qemu-system-x86_64"
|
||||
|
|
@ -36,7 +36,6 @@ COREOS_IMAGE_BASE_INSTALL = '\
|
|||
efibootmgr \
|
||||
efivar \
|
||||
os-release \
|
||||
${COREOS_IMAGE_EXTRA_INSTALL} \
|
||||
'
|
||||
|
||||
COREOS_IMAGE_EXTRA_INSTALL ?= ""
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ python check_coreos_sanity_eventhandler() {
|
|||
" `require conf/distro/belden-coreos.conf`"
|
||||
)
|
||||
|
||||
if e.data.getVar('VIRTUAL-RUNTIME_init_manager') != "systemd":
|
||||
if e.data.getVar('INIT_MANAGER') != "systemd":
|
||||
bb.fatal(
|
||||
"systemd is not set as `INIT_MANAGER`. "
|
||||
"Using SystemD is mandatory on CoreOS based distribution"
|
||||
|
|
|
|||
Loading…
Reference in New Issue