Based on the following patch:
Subject: [meta-virtualization][PATCH] image-oci-umoci: preserve file modes in rootfs
From: "Florian Wickert via lists.yoctoproject.org" <FlorianWickert=gmail.com@lists.yoctoproject.org>
cp does not preserve file modes by default.
This will break sudo (among others) which needs the suid flag to do its
work.
This patch adds the --preserve=mode flag to the cp call to fix this.
Signed-off-by: Florian Wickert <FlorianWickert@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The xen host image reference needed signifant work to be
functional for launching and testing Xen domu guests.
Here we add additional tools to the host image, and allow
it to automatically bundle guests if the configuration
is enabled.
We also add systemd networking configuration to create
a xenbr0 which offeres connectivity to the entire reference
system.
See the recipes and the README for details on testing
and bundling.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Adding a simple bbclass that when inherited appends do_compile
to emit a warning that the recipe will be removed in the future.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The OCI_IMAGE_TAG variable can contain a ":" if the user wants to give
the image a name and a tag, as in:
OCI_IMAGE_TAG = "${IMAGE_BASENAME}:latest"
However, while this is valid for tag name, the ":" is illegal in OCI
image file names so replace it with "_" when naming the symlinks
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Quote the label argument passed to umoci to allow it to correctly handle
spaces. Note that this requires that OCI_IMAGE_LABELS have the argument
quoted with single quotes, as in:
OCI_IMAGE_LABELS = "org.opencontainers.image.description='${SUMMARY}'"
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Quote the environment variable argument passed to umoci to allow it to
correctly handle spaces. Note that this requires that OCI_IMAGE_ENV_VARS
have the argument quoted with single quotes, as in:
OCI_IMAGE_ENV_VARS = "FOO='bar bat'"
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
umoci can encode both entrypoint and cmd lists into the oci image.
This is done by using the --config.entrypoint and --config.cmd arguments
multiple times.
We can split our OCI_* variables on space and support multiple arguments
in either command and keep compatibility with existing users.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The container stack flexibilty features set defaults (like other
parts of the layer) when 'virtualization' is in the distro features.
That reqirement means that the recipes fail parsing and QA checks
when the distro feature isn't enabled.
The defaults are currently safe for a virtualization enabled and
disabled configuration, so we include them in either case.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
From the configuration file itself:
These variables represent groupings of functionality in the CNCF
landscape. In particular, they are areas where there is a choice
between more than one implementation or an area where abstraction
is beneficial.
The contents of the variables are are runtime components that
recipes may use for RDEPENDS.
Build dependencies are not typically flexible, so do not currently
have DEPENDS equivalents for the components (i.e. DEPENDS on runc
versus crun).
Distro features such as kubernetes or other container stacks
can be used to set different defaults for these variables.
Note: these are "global" values, since they represent choices.
If more than of a grouping is required on target, then the variable
can be appended or set to multiple values. That being said, Recipes
should generally agree on the values, hence the global namespace.
Recipe specific choices can still be done, but they risk
conflicting on target or causing runtime issues / errors.
## CNCF "components"
# engines: docker-ce/docker-moby, virtual-containerd, cri-o, podman
VIRTUAL-RUNTIME_container_engine ??= "podman"
# runtime: runc, crun, runv, runx
VIRTUAL-RUNTIME_container_runtime ??= "virtual-runc"
# networking: cni, netavark
VIRTUAL-RUNTIME_container_networking ??= "cni"
# dns: cni, aardvark-dns
VIRTUAL-RUNTIME_container_dns ??= "cni"
# orchestration: k8s, k3s
VIRTUAL-RUNTIME_container_orchestration ??= "k3s"
## Kubernetes terminology "components"
VIRTUAL-RUNTIME_cri ??= "containerd"
VIRTUAL-RUNTIME_cni ??= "cni"
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Introducing a small (at the moment) class that represents configuration
and processing required to prepare a target image to be a container
host.
A recipe that requires container configuration should inherit this
class, and the container-host-config package will be added as a
RDEPENDS, and install common configuration files.
In the future, additional functionality or dependencies will be added
here to synchronize the configuration of multiple container host
packages.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The original tar output of the oci image followed the sloci-image
convention of putting the oci contents into a subdirectory in the
tarball. This allows it to work directly with skopeo, etc, but it
isn't the format that tools like podman expect in an oci-image
tarball.
We move the original format to have "-dir" in the name, and let
the more simply named one be the oci-image format as expcted by
various 3rd party tools
1) image_name.tar: compatible with oci tar format, blobs and
rootfs are at the top level. Can load directly from something like podman
2) image_name-dir.tar: original format from meta-virt, is just a
tar'd up oci image directory (compatible with skopeo :dir format)
We also fix a bug in the sloci-image backend, where the sloci tar
was removing the raw oci image directory leaving a dangling symlink.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
We have been symlinking the -oci image directory for a while, but
we can also create a shorted convenience symlink for the tar'd
version of that directory.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
To sync the sloci OCI image backend with the umoci variant, create
shortened convenience symlinks for the image and image.tar in the
deploy directory.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Symlink the date-time based image name, to just the imagename-oci.
This makes scripting use of the deployed container much simpler.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add an optional parameter that allows to override the stop
signal that is used.
Signed-off-by: Vasileios Anagnostopoulos <vasileios.anagnostopoulos@siemens.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
By default, highmem option is enabled for machine types later than
virt-2.12. This allows qemu to place devices and RAM in physical
address space above 32-bits. This can cause issues as according to the
documentation Xen supports up to 12GiB of physical address space.
Recently the issue was observed using runqemu, that was causing Linux
running on top of Xen to stall when trying to access ECAM space placed
by qemu at 256GiB mark. Even though this issue is most probably related
to QEMU and not Xen (the investigation showed that it can map ECAM
space correctly), it is best to avoid such issues by disabling highmem
on qemuarm.
Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
This reverts commit fb0a7b97db.
Justification:
Commit fb0a7b97db removed the PCI node from the qemu device tree
due to the issue when trying to access PCI configuration space that
was causing Linux running on top of Xen to end up in an infinite loop.
The investigation showed that the problem occurs due to qemu placing
ECAM space at 256GiB mark. Even though Xen officially supports on arm32
up to 12GiB of physical address space, it is able to map it correctly
for dom0. However, when Linux tries to access the ECAM space and the
stage2 translation fault occurs, HPFAR register contains incorrect IPA.
We can say it is incorrect because using hardware AT instruction or
software lookup, we can obtain the correct IPA from the same VA. This
can suggest that the problem is related to QEMU fault handling.
Instead of removing the PCI node the follow-up commit will disable
highmem option in qemu which will cause placing ECAM space in the
32-bit space.
Signed-off-by: Michal Orzel <michal.orzel@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Remove the pci node from the qemu device tree when runqemu is used with
xen-qemuboot.
Linux is ending up in an infinite loop when trying to access PCI
configuration space when running on top of Xen on arm32.
As we do not need or support any of the devices on PCI on arm32 at the
moment, just remove the node from the device tree generated by qemu.
The problem does not appear at the moment without Xen and it is unclear
why it is with Xen.
This will be investigated but in the meantime provide a working
configuration for users.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add required variables to generate a qemuboot devicetree for qemuarm.
With this change, Xen and dom0 can be started using runqemu.
Xen is started using qemu kernel argument and the devicetree is modified
to properly boot dom0 (which is loaded in memory).
This is using the same system as qemuarm64.
At this stage dom0 is hanging on PCI device scanning.
This patch is also using qemuarm64 as machine for arm64 bit instead of
aarch64 to allow adding support for other machine (an example a Xilinx
board that can be emulated with using an other xen machine).
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Fix qemuboot-xen-dtb to properly add dom0 bootargs by using a parameter
instead of directly using the QB_XEN_DOM0_BOOTARGS inside the function.
When not done, the variable is empty and dom0 bootargs are wrong in the
device tree.
Use QB_MACHINE to generate a device tree with qemu instead of always
using the armv8 machine. This will allow this class to be used for other
machines later.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Networking for Xen guest virtual machines is commonly configured via
bridging in the host system between a physical interface and the
guest virtual interfaces.
To make it easier to test networking and use testimage with Xen guest
virtual machines, extend the bbclass that provides network configuration
for qemu machines for the Xen images to configure a Xen bridge and put
eth0 onto it when QB_XEN_HOST_BRIDGE is set.
Signed-off-by: Christopher Clark <christopher.clark@starlab.io>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The Xen hypervisor built for Arm 32-bit targets can be launched with
runqemu by providing a u-boot script and configuration for Qemu, which
enables interactive testing of Xen images.
Add qemuboot-xen-u-boot.bbclass to add a new bitbake task for generating
the u-boot script. Since this increases the number of qemuboot-specific
classes that are inherited by the xen-image-minimal recipe, change the
inherit of all of these to only apply to qemu machines with the qemuall
override.
Update qemuboot-xen-defaults.bbclass to supply working default
parameters for the qemuarm machine needed to boot successfully in
testing. Also change all the arch-specific variable overrides into
narrower qemu platform overrides instead to avoid unnecessary
interactions with other Arm platform machines.
Signed-off-by: Christopher Clark <christopher.clark@starlab.io>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Overriding hostname in a .conf file, via base-files:
HOST_NAME="k3s-host"
hostname_pn-base-files = "${HOST_NAME}"
Is always a valid option, but if it is not configured, we can easily
have two hosts with the same name on the network, confusing adddress
assignement, etc.
This commit introduces a way to generate a unique hostname based
on the uuid of the build host, and the machine being built.
If virt-unique-hostname is added to IMAGE_FEATURES, like the following:
IMAGE_FEATURES += "virt-unique-hostname"
IMAGE_FEATURES[validitems] += "virt-unique-hostname"
Then a rootfs postprocessing hook will override hostnae to something
unique.
Note: this means your image will be reproducible on a single builder,
but not between them.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add a new minimal OEQA test case to run the Xen Test Framework
test runner in the standard testimage step. Tested with qemux86-64
and designed for compatibility with Arm when XTF supports it.
To enable, append to local.conf:
INHERIT += "testimage"
QEMU_USE_SLIRP = "1"
TEST_SERVER_IP = "127.0.0.1"
To run: bitbake -c testimage xtf-image
For inspection while it runs, at another shell prompt:
* Observe the image booting:
tail -f ${TMPDIR}/work/qemux86_64-*/xtf-image/*/testimage/qemu_boot_log.*
* Observe the tests running once boot has completed:
tail -f ${TMPDIR}/work/qemux86_64-*/xtf-image/*/temp/log.do_testimage
The XTF test sequence by default is a single XTF test case with minimal
hardware dependency to ensure that Xen is running, the Xen toolstack is
functional and XTF works. Additional XTF test cases for an image can be
configured via variables that are documented in the OEQA test case:
* XTF_TEST_CASES_POPULATE
* XTF_TEST_CASES_SKIP
* XTF_TEST_CASES_REQUIRE
Since testimage requires a functioning network to perform the tests on
the image and the qemu MACHINES do not have networking enabled
this commit provides a new qemuboot-testimage-network bbclass to add an
image postprocess command to enable a functional eth0 for qemu MACHINES.
Signed-off-by: Christopher Clark <christopher.clark@starlab.io>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
OEcore/bitbake are moving to use the clearer ":" as an overrides
separator.
This is pass one of updating the meta-virt recipes to use that
syntax.
This has only been minimally build/runtime tested, more changes
will be required for missed overrides, or incorrect conversions
Note: A recent bitbake is required:
commit 75fad23fc06c008a03414a1fc288a8614c6af9ca
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Sun Jul 18 12:59:15 2021 +0100
bitbake: data_smart/parse: Allow ':' characters in variable/function names
It is becomming increasingly clear we need to find a way to show what
is/is not an override in our syntax. We need to do this in a way which
is clear to users, readable and in a way we can transition to.
The most effective way I've found to this is to use the ":" charater
to directly replace "_" where an override is being specified. This
includes "append", "prepend" and "remove" which are effectively special
override directives.
This patch simply adds the character to the parser so bitbake accepts
the value but maps it back to "_" internally so there is no behaviour
change.
This change is simple enough it could potentially be backported to older
version of bitbake meaning layers using the new syntax/markup could
work with older releases. Even if other no other changes are accepted
at this time and we don't backport, it does set us on a path where at
some point in future we could
require a more explict syntax.
I've tested this patch by converting oe-core/meta-yocto to the new
syntax for overrides (9000+ changes) and then seeing that builds
continue to work with this patch.
(Bitbake rev: 0dbbb4547cb2570d2ce607e9a53459df3c0ac284)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The qemuboot device tree generation task in qemuboot-xen-dtb.bbclass
requires the QB_SYSTEM_NAME variable to be set to identify the Qemu
binary to use. Skip the task if it is not set.
Reported-and-tested-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Christopher Clark <christopher.clark@starlab.io>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The Xen hypervisor built for Arm 64-bit targets can be launched with
runqemu by providing a Device Tree binary and configuration for Qemu,
which enables interactive testing of Xen images.
Add qemuboot-xen-dtb.bbclass to add a new bitbake task for generating
the dtb file by using lopper on a device tree produced by Qemu.
Add qemuboot-xen-defaults.bbclass to supply working default parameters
for the qemuarm64 machine and general support for qemuboot for Xen,
and adjust the defaults as needed to boot successfully in testing.
Development aided by this script by Stewart Hildebrand of DornerWorks:
https://gist.github.com/stewdk/110f43e0cc1d905fc6ed4c7e10d8d35e
Signed-off-by: Christopher Clark <christopher.clark@starlab.io>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
As part of allowing different types of oci images to be created,
we split our IMG_cmd into .inc files that can then be specific to
the selected type.
For the umoci backend: We can take the same options as sloci
expects and use umoci to create images.
The resulting OCI image is similar, but by using umoci, we set
the stage to do multi-tag, or multi-layer images in the future.
But for now, we are functionally equivalent to the sloci backend.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The sdcard class in the meta-raspberrypi layer is now extensible with
support for adding files such as hypervisor binaries to the boot
partition, so this layer can switch to use that and drop the custom
sdcard bbclass.
Uses the new RPI_SDIMG_EXTRA_DEPENDS and DEPLOYPAYLOAD variables,
and: IMAGE_CLASS: sdcard_image-rpi-xen => sdcard_image-rpi
IMAGE_FSTYPE: rpi-xen-sdimg => rpi-sdimg
Please note that the filename suffix of the image is changed by this.
Also apply _raspberrypi4-64 scoping to the Raspberry Pi settings.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
At the moment the regular meta-raspberrypi SD card class does not allow
for optional inclusion of extra files in the SD card boot partition
without requiring those same files be present in the root filesystem.
This affects hypervisor binaries, such as Xen, which do not necessarily
belong within the guest filesystem.
As a workaround, inherit the sdcard_image-rpi.bbclass and clone the
main IMAGE_CMD function, adding the Xen-specific deploy that is needed.
This can be retired when the parent class has extensibility added.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
These settings are necessary for Xen and enabling them here, using the
same mechanism that is used by k8s in this layer, simplifies building
images for Xen.
- Ensure that Xen mode is enabled in QEMU.
- On ARM platforms: enable Flattened Device Tree (FDT) support.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
We were using USER_CLASS loading to allow conditional checking
on DISTRO_FEATURES, which triggered distro feature specific version
pinning.
It was found that DISTRO_FEATURES set in local.conf is not
consistently available at layer.conf parse time, hence our checks
were not always working as expected (i.e. the version files are
not included).
If we move the DISTRO_FEATURE check to the bbclasses, and use it
to trigger the include, we should have a consistent set of variable
resolution and consistent behaviour.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add support for a new distro feature to control kubernetes versions
and related configuration.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
This image class creates an oci image spec directory from a generated
rootfs. The contents of the rootfs do not matter (i.e. they need not be
container optimized), but by using the container image type and small
footprint images, we can create directly executable container images.
Once the tarball (or oci image directory) has been created of the OCI
image, it can be manipulated by standard tools. For example, to create a
runtime bundle from the oci image, the following can be done:
Assuming the image name is "container-base":
If the oci image was a tarball, extract it (skip, if a directory is being directly used)
% tar xvf container-base-<arch>-<stamp>.rootfs-oci-latest-x86_64-linux.oci-image.tar
And then create the bundle:
% oci-image-tool create --ref name=latest container-base-<arch>-<stamp>.rootfs-oci container-base-oci-bundle
Or to copy (push) the oci image to a docker registry, skopeo can be used (vary the
tag based on the created oci image:
% skopeo copy --dest-creds <username>:<password> oci:container-base-<arch>-<stamp>:latest docker://zeddii/container-base
The following image variables are available to customize the details
of the constructed image (defaults as shown):
OCI_IMAGE_AUTHOR ?= "${PATCH_GIT_USER_NAME}"
OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"
OCI_IMAGE_TAG ?= "latest"
OCI_IMAGE_RUNTIME_UID ?= ""
OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
OCI_IMAGE_ENTRYPOINT ?= "sh"
OCI_IMAGE_ENTRYPOINT_ARGS ?= ""
OCI_IMAGE_WORKINGDIR ?= ""
//List of ports to expose from a container running this image:
//PORT[/PROT]
// format: <port>/tcp, <port>/udp, or <port> (same as <port>/tcp).
OICI_IMAGE_PORTS ?= ""
// key=value list of labels
OCI_IMAGE_LABELS ?= ""
// key=value list of environment variables
OCI_IMAGE_ENV_VARS ?= ""
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The ConfigParsed event is raised multiple times during a build which resulted
in the sanity warning appearing up to 4 times per build. Instead we should be
watching for the SanityCheck event (this is what the sanity checks in oe-core
watch for).
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
The variable used to skip the sanity check should be named in a layer specific
way. This will ensure there is no confusion if other layers use a similar sanity
check.
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Add a new class, sanity-meta-virt.bbclass, to check for whether necessary
settings are available for bbappend files in this layer to be effective,
and warn users if not.
In addition, a variable SKIP_SANITY_BBAPPEND_CHECK is added to enable users
to explicitly skip the checking to avoid unwanted warnings.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Continue work to use go infra in oe-core instead of the support for go
previously found in meta-virt. This is a 1:1 drop in replacement and
removes one more go piece from meta-virt in favor of the common
support found in oe-core.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
getVar() now defaults to expanding by default.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Building any recipe for a mips-based machine like arduino-yun currently leads
to errors in go_map_arch(). Instead, errors should only be raised if a recipe
which uses golang is built. This is achieved using the same error handling seen
in recipes-extended/xen.
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
