linux/meta-virtualization.git, branch master

tests: fix lxc lifecycle suite hang and tighten download-skip predicate

2026-06-15T15:22:44+00:00

Two diagnostics-quality fixes to test_lxc_runtime.py uncovered by running the full suite after lxc-networking landed in the lxc profile: 1. test_start used `exit $rc` after the lxc-start invocation to propagate the exit code through run_cmd's marker harness. With lxc-networking now installed, lxc-start succeeds (rc=0) and the `exit 0` terminates the guest's interactive login shell, which triggers getty respawn. Every subsequent lifecycle test then times out waiting for its marker because the new getty is sitting at the login prompt with no auto-login. Wrap the cleanup in `( exit $LXC_RC )` so only a subshell exits; the outer login shell stays alive for the next test. While here, pre-flight checks for lxc-net.service and the lxcbr0 link surface in the failure message — the "ABORTING" path that bit us during bring-up gave no hint which precondition was missing. 2. test_create_alpine_via_download treated any non-zero lxc-create rc as "network unreachable" and skipped. That swallowed a stale "Container already exists" left over from an interrupted previous run (or from manual poking), silently turning a real test-harness bug into a green skip. Pre-clean with `lxc-destroy --force` (best-effort, ignores rc), then match a list of known network-error markers explicitly. Any other failure is a real bug and fails the test with the full lxc-create output instead of hiding behind pytest.skip. Signed-off-by: Bruce Ashfield

tests: use CONTAINER_PROFILE and surface runqemu errors in lxc fixture

2026-06-15T14:13:10+00:00

Two correctness improvements to the lxc runtime test fixture. 1. Switch the build from CONTAINER_IMAGE_HOST_EXTRA_INSTALL = "lxc" to CONTAINER_PROFILE = "lxc". The original fixture set CONTAINER_IMAGE_HOST_EXTRA_INSTALL to force lxc into the rootfs without depending on a profile fragment, because at the time no lxc profile existed. Now that container-host-lxc.conf is in tree, the test should exercise the same path real users take — which is the entire point of a runtime test. Using the profile also pulls in lxc-networking and lxc-templates automatically (via packagegroup-lxc), where the original "just install lxc" approach silently left a half-broken LXC the test couldn't usefully verify. 2. Capture the runqemu output to a file and surface it in the pexpect.EOF failure message. pexpect's default 100-character "before" buffer truncates runqemu's actual error to the trailing fragment, which is rarely enough to diagnose the failure. Boot failures during fixture setup now print the last 60 lines of the runqemu log into the pytest failure message and leave the full log at /tmp/test_lxc_runtime-runqemu.log for follow-up. When the lxc image still wasn't booting cleanly, this is what made the "lxc-net.service could not be found" / bridge-missing root cause visible without re-instrumenting the fixture. Signed-off-by: Bruce Ashfield

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

packagegroup-lxc: pull in networking and templates explicitly

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

packagegroup-lxc is documented as the "ready-to-use LXC" group but its RDEPENDS only listed the lxc package itself, not the networking or templates sub-packages required for a functional LXC. With the matching change to the lxc recipe (RRECOMMENDS adding both sub-packages to anyone installing lxc), this packagegroup would now pick them up transitively — but listing them in RDEPENDS here keeps the packagegroup honest as a self-contained specification of what it provides, and guards against future BAD_RECOMMENDATIONS in a downstream distro silently turning packagegroup-lxc back into "just the binaries." This is the path container-image-host takes when VIRTUAL-RUNTIME_container_engine is set to "lxc", so it's also the path the just-added container-host-lxc profile fragment exercises. Signed-off-by: Bruce Ashfield

lxc: pull in networking and templates via RRECOMMENDS

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

The lxc recipe ships three sub-packages: ${PN}, ${PN}-networking, and ${PN}-templates. ${PN} contains the lxc-* command-line binaries. ${PN}-networking owns lxc-net.service, /etc/default/lxc-net, the dnsmasq drop-in for the lxcbr0 bridge, and the firewall plumbing. ${PN}-templates owns /usr/share/lxc/templates, the per-distro container-creation scripts that lxc-create invokes via --template. Installing only the main ${PN} package leaves a non-functional LXC. There's no lxcbr0 bridge, so any container whose config references it (every download-template default config does) fails to start with network.c: netdev_configure_server_veth: Failed to attach "vethXXX" to bridge "lxcbr0", bridge interface doesn't exist and there are no template scripts, so lxc-create --template has nothing to invoke. The user-facing toolchain is effectively broken unless the integrator knows to add the sub-packages by hand. Pull both sub-packages in through RRECOMMENDS so any image that installs lxc gets a functional LXC by default, regardless of whether the install path is packagegroup-lxc, IMAGE_INSTALL:append, or CORE_IMAGE_EXTRA_INSTALL. Integrators who don't want them (custom networking, hand-written templates) can drop either or both through BAD_RECOMMENDATIONS. Signed-off-by: Bruce Ashfield

tests: add lxc runtime tests with download-template regression

2026-06-14T03:57:14+00:00

The "lxc was tested" claim during the recent runtime testing sweep was actually transitive — incus runs against LXC libraries under the hood, so incus passing was treated as evidence that LXC itself worked. That inference was wrong: incus uses its own go bindings into liblxc rather than the lxc-* command-line tools, and the breakage Ferry Toth reported on 2026-06-13 sat entirely in templates/lxc-download.in (a script invoked by lxc-create, never reached through incus). The bug would not have been caught by any existing test in the layer. Add tests/test_lxc_runtime.py to close the gap. The suite boots container-image-host with CONTAINER_IMAGE_HOST_EXTRA_INSTALL=lxc, then runs three groups of checks against the live guest: TestLxcInstalled — sanity that lxc-create, lxc-start and lxc --version work at all. Catches packaging and PATH-level regressions. TestLxcDownloadTemplate — explicit regression for the templates-actually-create-DOWNLOAD_TEMP-directory.patch failure mode. Runs `lxc-create --template download` and asserts the broken early-mktemp error string ("mktemp: failed to create file via template '-d…") does not appear in the output. We deliberately do not require the download itself to succeed — the bug fires before any HTTP request, so the test stays meaningful on air-gapped CI where the actual fetch would fail for unrelated reasons. TestLxcContainerLifecycle (@pytest.mark.network) — full end-to-end: create from images.linuxcontainers.org, start, attach, stop, destroy. Marked @network so offline runners deselect it cleanly. The regression test above is the primary guard; this is depth. Also register the lxc marker in pytest.ini so collection doesn't warn. The test conventions (pexpect-driven runqemu boot, marker-delimited command runner, TERM=dumb to suppress shell integration escape sequences) match test_incus_runtime.py and test_xen_runtime.py so the three suites read consistently. Signed-off-by: Bruce Ashfield

lxc: drop templates-actually-create-DOWNLOAD_TEMP-directory.patch

2026-06-14T03:56:57+00:00

The local patch added in 2018 was meant to ensure DOWNLOAD_TEMP pointed at a directory that actually existed by routing mktemp through the -p option. Its else branch is reached precisely when DOWNLOAD_TEMP is unset (the elif catches the set case), but the rewrite DOWNLOAD_TEMP="$(mktemp -p ${DOWNLOAD_TEMP} -d)" substitutes an empty ${DOWNLOAD_TEMP} into the command line, leaving the shell to parse mktemp -p -d as -d being the argument value for -p rather than its own flag. mktemp then fails immediately with mktemp: failed to create file via template '-d/tmp.XXXXXXXXXX': No such file or directory and lxc-create exits before doing any network work. Every invocation of lxc-create --template download is broken. Ferry Toth reported this on the meta-virt list 2026-06-13 (subject "lxc: starting a container errors out"). His diagnosis is correct and the fix he proposed — drop the patch — is the right one. The original upstream line DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)" handles both cases correctly: with DOWNLOAD_TEMP set the elif branch runs first, and with it unset the else branch reduces to just DOWNLOAD_TEMP="$(mktemp -d)" which lets mktemp pick the default TMPDIR / /tmp location and create the directory. The original 2018 motivation ("DOWNLOAD_TEMP will not be pointing to an actual directory") does not match how mktemp -d actually behaves on modern systems — the directory IS created, and that's the whole point of mktemp -d. The reported failure mode was likely a build-host environment quirk specific to that 2018 setup rather than a general bug worth carrying a layer-local patch for. Signed-off-by: Bruce Ashfield

container-bundle: add CONTAINER_FLAGS_ACCEPTED to acknowledge container licenses

2026-06-13T03:51:50+00:00

container-bundle.bbclass emits a bb.warn on every parse of a recipe that fetches a remote container. The warning's intent is sound: the integrator is shipping content they did not build from source, and the license/redistribution implications deserve a deliberate review. After that review has happened, though, the warning has nowhere to go. It keeps firing on every build, and there is no way for an image recipe that intentionally bundles e.g. an alpine or busybox base container to have a clean parse log. Users who want to add deliberate third-party base images (the app-container-alpine demo Tim is working on is the immediate motivation) end up either editing the bbclass to suppress the warning entirely or living with the noise — both bad. Add CONTAINER_FLAGS_ACCEPTED, mirroring oe-core's LICENSE_FLAGS / LICENSE_FLAGS_ACCEPTED pattern. The recipe never declares its own container licenses as accepted; instead the integrator opts in via local.conf or distro config after reviewing each container: CONTAINER_FLAGS_ACCEPTED += "docker.io/library/alpine" URLs in CONTAINER_FLAGS_ACCEPTED are matched against both the full URL (with :tag or @digest) and the bare URL with tag/digest stripped, so accepting "docker.io/library/alpine" covers every tag of that container. A "*" wildcard accepts every third-party container — for distros that have a standing review process. When a URL matches, the bb.warn is demoted to a bb.note instead of being silenced entirely. The note remains in the build log and the recipe's task log, so SBOM tools, audit pipelines, and distro release reviews can still see that an acknowledged third-party container was pulled. The point of the change is to remove the visible "WARNING" line from clean builds, not to hide that the fetch happened. The unacknowledged-URL warning is also reworded to print a copy-pasteable CONTAINER_FLAGS_ACCEPTED line for the specific URL, so the user reading the warning doesn't have to grep the docs to find the variable name. Documentation lives in both the bbclass header block and docs/container-bundling.md (under a new "Acknowledging Third-Party Container Licenses" section), with the exact warning text and the exact note text quoted so they're greppable from either entry point. Signed-off-by: Bruce Ashfield

vcontainer-tarball: unset OECORE_NATIVE_SYSROOT in CI

2026-06-13T03:35:33+00:00

Add 'unset OECORE_NATIVE_SYSROOT' to the end of environment-setup-ci for the same reasons it needed to be in environment-setup-none. This fixes issues seen on AutoBuilder workers which use buildtools-tarball and also usage of oe-run-native (e.g. for skopeo-native or cosign-native). Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield

tests: add requirements.txt

2026-06-12T18:48:59+00:00

Add requirements.txt to allow versions to be pinned. Signed-off-by: Tim Orling Signed-off-by: Bruce Ashfield