meta-belden-bsp: add containers machine

documentation/index.rst

@@ -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

documentation/ref-manual/index.rst

@@ -11,6 +11,7 @@ Belden CoreOS Reference Manual
 
    classes
    distro
+   machines
    images
    features
    variables

documentation/ref-manual/machines.rst

@@ -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.
+

documentation/using-container.rst

@@ -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.

layers/meta-belden-coreos-bsp/conf/machine/container-arm32.conf

@@ -0,0 +1,2 @@
+require include/coreos-generic-arch/arm32.inc
+require include/coreos-generic-machine/container.inc

layers/meta-belden-coreos-bsp/conf/machine/container-arm64.conf

@@ -0,0 +1,2 @@
+require include/coreos-generic-arch/arm64.inc
+require include/coreos-generic-machine/container.inc

layers/meta-belden-coreos-bsp/conf/machine/container-x64.conf

@@ -0,0 +1,2 @@
+require include/coreos-generic-arch/x64.inc
+require include/coreos-generic-machine/container.inc

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-arch/arm32.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

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-arch/arm64.inc

@@ -0,0 +1,2 @@
+DEFAULTTUNE ?= "aarch64"
+require conf/machine/include/arm/arch-arm64.inc

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-arch/x64.inc

@@ -0,0 +1,2 @@
+DEFAULTTUNE ?= "core2-64"
+require conf/machine/include/x86/tune-core2.inc

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-machine/container.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 = ""

layers/meta-belden-coreos-bsp/conf/machine/include/coreos-generic-machine/vm.inc

@@ -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.bmap wic.vmdk iso"
+IMAGE_FSTYPES += "ext4 wic wic.bmap wic.vmdk"
 
 WKS_FILE ?= "generic-uefi.wks.in"
 EFI_PROVIDER ?= "systemd-boot"

layers/meta-belden-coreos-bsp/conf/machine/vm-x64.conf

@@ -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 include/coreos-generic-arch/x64.inc
-require conf/machine/include/x86/tune-core2.inc
+require include/coreos-generic-machine/vm.inc
-require conf/machine/include/pc-common.inc
 
 SERIAL_CONSOLES_CHECK = "ttyS0"
-#For runqemu
 QB_SYSTEM_NAME = "qemu-system-x86_64"

layers/meta-belden-coreos/classes/coreos-image.bbclass

@@ -33,7 +33,6 @@ COREOS_IMAGE_BASE_INSTALL = '\
     packagegroup-core-boot \
     packagegroup-base-extended \
     \
-    ${COREOS_IMAGE_EXTRA_INSTALL} \
     '
 
 COREOS_IMAGE_EXTRA_INSTALL ?= ""

layers/meta-belden-coreos/classes/coreos-sanity.bbclass

@@ -17,7 +17,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"