linux/meta-virtualization.git, branch master

conf: add kvm-host.conf configuration fragment

2026-05-12T12:52:59+00:00

Building kvm-image-minimal fails without the 'kvm' DISTRO_FEATURE, requiring users to manually add it to local.conf. Every other virtualization platform (Xen, Docker, Podman, k3s, containerd) already has a composable configuration fragment in conf/distro/include/ that can be included with a single require line. Add kvm-host.conf following the same pattern as xen-host.conf: a pure delta fragment that appends the kvm DISTRO_FEATURE. Composable with any container profile and the base meta-virt-host.conf. Signed-off-by: Bruce Ashfield

xen: fix buildpaths QA errors for hypervisor EFI and debug packages

2026-05-12T12:52:48+00:00

Xen's hypervisor Makefile overrides CFLAGS entirely with its own flags (nostdinc, fno-builtin, etc.), so OE's DEBUG_PREFIX_MAP flags added via CFLAGS never reach the hypervisor compilation. The existing prefix map entries in xen.inc appeared to work only because sstate was caching pre-built packages — a fresh rebuild exposes the embedded TMPDIR paths in the EFI binary and debug symbols. Inject the prefix maps through EXTRA_CFLAGS_XEN_CORE, which is Xen's own mechanism for accepting additional compiler flags and is already passed through to oe_runmake. This fixes the EFI binary paths. The xen-syms debug binary retains one source path in .debug_str from the linker/assembly stage, which does not honor the C compiler's -fdebug-prefix-map. Since xen-syms is only shipped in the -dbg package (not a deployment target), skip buildpaths for xen-dbg. This is an optional QA test — not in CHECKLAYER_REQUIRED_TESTS — so it has no impact on yocto-check-layer compatibility. Signed-off-by: Bruce Ashfield

libvirt: fix python3 compatibility in hook_support.py

2026-05-11T20:15:08+00:00

By default Popen expects all the streams to be bytes-like objects but, in the Popen.communicate() function call, the "input" argument is a string, making the call fail with the error: qemu hook error: a bytes-like object is required, not 'str' Fix the error by setting text mode to True in the subprocess creation. Also fix the "SyntaxWarning: invalid escape sequence '\w'" in the regex used to match script names. Signed-off-by: Massimiliano Minella Signed-off-by: Bruce Ashfield

image-oci: don't preserve ownership in directories/files/host layer copies

2026-05-11T20:11:22+00:00

The multi-layer 'directories', 'files', and 'host' branches in IMAGE_CMD:oci copy delta content into the OCI bundle rootfs with 'cp -a'. 'cp -a' implies '--preserve=all', which calls lchown() on the destination to copy ownership from the source. When a directories/files layer copies a symbolic link whose target does not exist at build time (for example, the '/dev/stdout' and '/dev/stderr' log forwarding symlinks used by the official nginx Docker image), lchown() can return EINVAL under pseudo and 'cp' aborts with: cp: failed to preserve ownership for .../var/log/nginx/access.log: Invalid argument failing the whole do_image_oci task. The single-layer rootfs copy already handles this correctly: cp -r -a --no-preserve=ownership ${IMAGE_ROOTFS}/* $image_bundle_name/rootfs and the multi-layer 'packages' branch uses 'rsync -a --no-owner --no-group' for the same reason. Bring the three remaining cp -a sites in line by adding '--no-preserve=ownership'. Ownership inside an OCI image is set by umoci based on the image config and source ownership has no meaning for symlinks to runtime device nodes anyway, so dropping preservation is the correct behaviour. Reproduce: declare a directories: layer that copies a path containing a symlink to '/dev/stdout' or '/dev/stderr' (e.g. a postprocess that creates /var/log/nginx/{access,error}.log -> /dev/{stdout,stderr} to mirror the upstream nginx Docker image). Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

podlet: add podlet utility

2026-05-11T20:11:11+00:00

Podlet generates Podman Quadlet files from a Podman command, compose file, or existing object. Signed-off-by: Patrick Vogelaar Signed-off-by: Bruce Ashfield

vcontainer: add BBMASK for parse savings and suppress layer warnings

2026-05-10T20:15:50+00:00

The initial vcontainer distro had no BBMASK at all, making it effectively poky with fewer DISTRO_FEATURES. Every multiconfig parsed the entire recipe universe even though container image builds only need a small subset. With 4+ multiconfigs, the parse overhead is significant. Add vcontainer-bbmask.inc as a lighter alternative to vruntime's aggressive BBMASK. It masks the same categories irrelevant to any container/VM build (graphics, multimedia, desktop, virtualization platforms, orchestration tools, meta-python, meta-filesystems, meta-webserver) but keeps the OCI tooling that vruntime blocks: umoci, container-registry, image recipes, sloci, oci-image-tools. Masking entire layers (meta-python, meta-filesystems, meta-webserver) produces BBFILE_PATTERN warnings because the layers are registered in bblayers.conf (shared with the main build) but have zero recipes after masking. BitBake provides BBFILE_PATTERN_IGNORE_EMPTY_ to suppress this, but checks it on self.data (the base datastore), not per-multiconfig datastores. Setting it in the distro config has no effect. Move the suppression to meta-virt-host.conf which is included by the main build's local.conf and therefore visible to the base datastore. Signed-off-by: Bruce Ashfield

container-registry: add multi-arch OCI push support and tests

2026-05-10T13:58:45+00:00

The registry push script (container-registry-index.bb) treated all OCI directories as single-arch, calling 'skopeo copy oci:' which fails with "more than one image in oci, choose an image" when the directory contains a multi-arch image index. The original push implementation predated multi-arch OCI support and only handled the single-manifest case. Detect multi-arch OCI Image Index directories (both flat and nested layouts) in the direct-path push mode and use 'skopeo copy --all' to push the entire manifest list to the registry in one operation. This preserves the multi-platform structure so that clients pulling from the registry automatically get the correct architecture. Also strip the '-multiarch' suffix from directory names when deriving the registry image name, so container-base-multiarch-multiarch-oci pushes as 'container-base' rather than 'container-base-multiarch'. Add build-profiles.md documentation for the vcontainer distro, container multiconfigs, and multi-arch container build workflow. Add test_vcontainer_distro.py with 54 tests across three tiers: - Tier 1: Static file assertions (vruntime-base.inc, vcontainer.conf, multiconfigs, bbclass defaults, recipe structure) - Tier 2: Cross-file consistency (shared base, distro-MC alignment, bbclass-to-multiconfig file matching) - Tier 3: Build output verification (OCI index structure, platform entries, blob integrity, manifest validation) Signed-off-by: Bruce Ashfield

vcontainer-common: support nested OCI layout and fix vimport shell errors

2026-05-10T13:58:27+00:00

The multi-arch OCI functions (is_oci_image_index, get_oci_platforms, select_platform_manifest) only checked index.json directly for platform information. With the skopeo-compatible nested OCI layout — where index.json references a single image index blob that in turn contains the per-platform manifests — the functions failed to detect multi-arch images because index.json no longer contains platform entries. Add _resolve_oci_platform_file() helper that handles both layouts: - Flat: platform info directly in index.json (legacy/simple case) - Nested: index.json → image index blob → platform manifests All three multi-arch functions now use this single helper, eliminating the layout resolution logic that would otherwise be duplicated in each. Also fixes two issues in the vimport case block: - 'local' keyword used outside a function (bash error on line 1879). The vimport handler is in a case statement in the main script body, not inside a function, so 'local' is invalid. The original multi-arch code was written assuming it would be inside a function. - OCI_SELECTED_PLATFORM was blank in output because select_platform_manifest sets it inside a $() subshell, where variable assignments are lost. Use normalize_arch_to_oci directly for the display message instead. Signed-off-by: Bruce Ashfield

oci-multiarch: fix MC defaults, deploy dependency, and OCI layout

2026-05-10T13:58:10+00:00

Three issues prevented oci-multiarch.bbclass from producing usable multi-architecture container images: 1. MC defaults pointed to vruntime-* multiconfigs, whose BBMASK blocks OCI tooling. Changed to container-* multiconfigs which use the new vcontainer distro without BBMASK. 2. mcdepends targeted do_image_oci, but the OCI output is only deployed to deploy/images/ by the later do_image_complete task. The bbclass then failed to find the OCI directory at the expected deploy path. The original implementation assumed do_image_oci was the final step, but OE-core's image pipeline has a separate deploy phase. 3. The OCI Image Index was written directly into index.json with multiple manifest entries. This is valid per the OCI spec but skopeo requires index.json to reference a single entry when there are multiple images. The fix writes the multi-platform image index as a blob in blobs/sha256/ and has index.json reference it with a single entry of mediaType application/vnd.oci.image.index.v1+json. This nested layout is what tools like buildah and crane produce for multi-arch images, and is required for 'skopeo copy --all' to work. Also adds container-base-multiarch.bb recipe that wires up container-base for aarch64 + x86_64 builds via the oci-multiarch class. Signed-off-by: Bruce Ashfield

vcontainer: add OCI builder distro with shared base

2026-05-10T13:57:50+00:00

The oci-multiarch.bbclass was dead code because vruntime's BBMASK blocks the OCI tooling (umoci, skopeo) needed to build container images. We could not simply use the vruntime multiconfigs for OCI image builds because the aggressive recipe masking that keeps vruntime rootfs minimal also removes the packages needed for container image creation. Rather than maintaining two independent distro configs with duplicated DISTRO_FEATURES, extract the common configuration into a shared base fragment and create a new distro that omits the BBMASK. Changes: - Extract vruntime-base.inc from vruntime.conf with shared settings: stripped DISTRO_FEATURES, opted-out features, native class overrides - Simplify vruntime.conf to require vruntime-base.inc, keeping only VM-specific settings (BBMASK, busybox init, ptest disable) - Add vcontainer.conf: requires the same shared base but without BBMASK, giving OCI tooling full access to the package set - Add container-aarch64 and container-x86-64 multiconfigs using the vcontainer distro with separate TMPDIRs - Add container multiconfigs to BBMULTICONFIG in meta-virt-host.conf - Remove unused container.conf placeholder from 2022 IMAGE_FSTYPES is intentionally NOT set in vcontainer.conf because the 'oci' type requires image-oci.bbclass which only container image recipes inherit. Setting it distro-wide breaks non-container images parsed under this distro (e.g., core-image-multilib-example from meta-skeleton). Signed-off-by: Bruce Ashfield