linux/meta-virtualization.git/conf/distro, branch master

container-host: add lxc profile

2026-06-15T14:12:57+00:00

conf/distro/include/ shipped fragments for docker, podman, containerd, incus, k3s, and k3s-node, with the indirection chain local.conf : require container-host-${BUILD_PROFILE}.conf container-host-FOO.conf : CONTAINER_PROFILE = "FOO" meta-virt-container-cfg.bbclass (USER_CLASSES): include meta-virt-container-${CONTAINER_PROFILE}.inc meta-virt-container-FOO.inc : VIRTUAL-RUNTIME_container_engine ??= "FOO" container-image-host.bb : contains_any('VIRTUAL-RUNTIME_container_engine', 'FOO', 'packagegroup-FOO', '', d) lxc was not part of that set, even though packagegroup-lxc existed. Integrators wanting a lxc-flavoured container-image-host had to either add lxc to CORE_IMAGE_EXTRA_INSTALL by hand or invent their own fragment. This commit fills in the three missing pieces so lxc becomes a peer of the existing engines: conf/distro/include/container-host-lxc.conf User-facing fragment. Sets CONTAINER_PROFILE = "lxc". This is the file integrators require from local.conf, same shape as the existing container-host-incus.conf. conf/distro/include/meta-virt-container-lxc.inc Resolved by meta-virt-container-cfg.bbclass from CONTAINER_PROFILE. Sets VIRTUAL-RUNTIME_container_engine ??= "lxc" and zeroes the OCI-shaped VIRTUAL-RUNTIME_container_runtime / _networking / _dns / _orchestration variables (LXC doesn't use any of the OCI engine model), matching the incus .inc. recipes-extended/images/container-image-host.bb Adds the lxc branch to the engine-selection block, alongside the existing docker / podman / containerd / incus checks. When VIRTUAL-RUNTIME_container_engine is "lxc", IMAGE_INSTALL gets packagegroup-lxc, which (with the recipe + packagegroup changes) is now lxc + lxc-networking + lxc-templates. After this change, setting BUILD_PROFILE = "lxc" in local.conf and building container-image-host produces a guest where lxc-create, lxc-start, lxc-attach, etc. work against the download template end-to-end. Signed-off-by: Bruce Ashfield

podman: switch from CNI to netavark as sole network backend

2026-06-04T03:31:56+00:00

Podman's vendored containers/common library removed CNI support entirely in commit 8d1f636e40 (March 2026). The NetworkBackend() function now unconditionally rejects any backend other than netavark, making network_backend = "cni" in containers.conf a runtime error. The vpdmn rootfs originally used CNI because netavark's dependency chain (nmap -> libpcap -> bluez5 -> cairo) was too heavy for the vruntime BBMASK environment. That dependency chain no longer exists — netavark v1.16.0+ uses a built-in Rust connection tester and has no heavyweight runtime dependencies. Recipe changes: - Clear BUILDTAGS_EXTRA default (was CNI build tag, now a no-op) - Set VIRTUAL-RUNTIME_container_networking and _container_dns with strong assignments so podman always RDEPENDS on netavark and aardvark-dns regardless of distro config - Remove ${sysconfdir}/cni from FILES vpdmn rootfs changes: - Replace cni with netavark + aardvark-dns in IMAGE_INSTALL - Update containers.conf network_backend from cni to netavark Signed-off-by: Bruce Ashfield

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

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

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

distro/vruntime: remove now uncessary DISTRO_FEATURES_DEFAULT

2026-04-28T11:27:58+00:00

DISTRO_FEATURES_DEFAULT has been obsoleted [1][2]. Follow the pattern in meta-yocto [3] and remove it. Fixes: ERROR: Nothing PROVIDES 'nativesdk-libseccomp' ... [1] https://git.openembedded.org/openembedded-core/commit/meta/conf?id=0548ea447445834647be7ef35ed0ae8d1d3387b3 [2] https://git.openembedded.org/openembedded-core/commit/meta/conf?id=159148f4de2595556fef6e8678578df83383857b [3] https://git.yoctoproject.org/meta-yocto/commit/?id=96085aaec5bfb33c4e4322465eaf0af370db6fc0 Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

incus: add container host profile

2026-04-09T03:32:12+00:00

Add CONTAINER_PROFILE=incus support so incus can be selected as the container engine for container-image-host: require conf/distro/include/container-host-incus.conf MACHINE = "qemux86-64" bitbake container-image-host Signed-off-by: Bruce Ashfield

k3s-host: set virtual-runc as container runtime

2026-04-06T23:49:24+00:00

The k3s-host container profile had VIRTUAL-RUNTIME_container_runtime set to empty, which meant no OCI runtime (runc or crun) was installed. containerd's RDEPENDS uses this variable to pull in the runtime, so k3s pods failed with "runc: executable file not found in $PATH". Set to virtual-runc which is what k3s expects. The k3s-node profile inherits from k3s-host so it gets the fix too. Signed-off-by: Bruce Ashfield

vruntime, vrunner, conftest: fix multiconfig and batch import issues

2026-04-06T23:48:37+00:00

vruntime.conf: - Reset all VIRTUAL-RUNTIME_container_* variables to prevent CONTAINER_PROFILE selections from leaking into vruntime multiconfigs (e.g., podman profile pulling netavark into vruntime builds) - Disable ptest for glib-2.0 — its -ptest RDEPENDS chain (python3-dbusmock -> python3-pygobject -> cairo -> fontconfig) pulls the entire graphics stack which is masked in vruntime - OE-core commit 159148f4de2 replaced DISTRO_FEATURES_BACKFILL_CONSIDERED with DISTRO_FEATURES_OPTED_OUT. The old variable no longer has any effect, which meant ptest, gobject-introspection-data, wayland, and other features were no longer being blocked in vruntime builds. This caused glib-2.0's ptest RDEPENDS to pull in the cairo → fontconfig → freetype graphics stack, which is masked by the vruntime BBMASK. - Set PREFERRED_PROVIDER_virtual/runc with strong assignment to ensure the unified runc recipe is used vrunner.sh: - Fix batch import exit code handling: wrap import chain in subshell and make the images listing best-effort. The previous '&& podman images' caused false failures when podman images couldn't initialize its network backend. Using 'exit' was also wrong as the command runs inside PID 1 init's eval — exit kills init causing kernel panic. vpdmn-rootfs-image.bb: - Switch from netavark to CNI networking — netavark's dependency chain (nmap -> libpcap -> bluez5 -> python3-pygobject -> cairo) cannot be built under the vruntime BBMASK environment - Add nsswitch.conf override (files-only backend) to prevent libnss_systemd segfaults — the vruntime VM uses busybox init with no systemd running, but libnss_systemd.so is pulled in as a dependency and segfaults on NSS resolution vdkr-rootfs-image.bb: - Document skopeo requirement for batch import conftest.py: - Add --k3s-timeout option and k3s/multinode markers for upcoming K3s test suite Signed-off-by: Bruce Ashfield

conf/distro: add build profile configuration fragments

2026-04-05T02:09:58+00:00

Add includable configuration fragments that replace manual DISTRO_FEATURES, CONTAINER_PROFILE, and related settings in local.conf. Fragments are organized as a base + composable deltas: - meta-virt-host.conf: base for all virtualization work (virtualization, systemd, seccomp, vmsep, vcontainer, BBMULTICONFIG) - container-host-{docker,podman,containerd,k3s,k3s-node}.conf: container engine profiles setting CONTAINER_PROFILE and profile-specific DISTRO_FEATURES - xen-host.conf: Xen hypervisor support (xen, vxn distro features, xen-image-minimal packages) - meta-virt-dev.conf: QEMU development settings (IMAGE_FSTYPES, QB_MEM, debug image features) - container-registry.conf: local dev registry defaults (insecure localhost:5000) Profiles are pure deltas and do not auto-include the base to avoid BitBake duplicate inclusion warnings. Users include meta-virt-host.conf first, then add profile fragments. The BUILD_PROFILE variable enables single-line profile switching. Usage in local.conf: require conf/distro/include/meta-virt-host.conf BUILD_PROFILE ?= "podman" require conf/distro/include/container-host-${BUILD_PROFILE}.conf Tested with podman, docker, and xen builds. Signed-off-by: Bruce Ashfield