Re: [meta-virtualization][PATCH 0/2] image-oci: two do_image_oci bugfixes (missing pm.update(), libgcc/libgcc-initial sysroot collision)

On Tue, Jul 28, 2026 at 7:56=E2=80=AFAM Koen Kooi via lists.yoctoproject.or=
g
<[email protected]> wrote:
>
> I've been working on a prototype for building a rootfs with multiple mult=
i-layer OCI images images, all built from scratch, in one bitbake command. =
I ran into some issues along the way:
>
> * image-oci never runs "opkg update" or its rpm equivalents, so nothing g=
ets installed
> * both libgcc-initial and libgcc want to be in the sysroot
>
> The first issue is straightforward, for the second I leaned heavily on Cl=
aude to write a proper python version and explain it better. I'm not fond o=
f the wall of text that ends up with, but this is already the 3rd iteration=
 of trimming it down.
>
> Anyway, This is the first wave, I'm working on other fixes, like mtime in=
fluencing base-layer sharing, but that needs more testing and review. I do =
need to mention how surprisingly small the resulting image recipes are, a b=
ig thanks to everyone who has been working on this!
>
> Below is what Claude suggested as coverletter, it is still verbose, but d=
oesn't suffer from the "Is Koen being sarcastic or not?" issue :)
>
> 1/2 - image-oci: call pm.update() before pm.install() for multi-layer
>       package layers
>
>   Multi-layer OCI images (OCI_LAYER_MODE =3D "multi") with a "packages:"
>   layer silently produce an empty layer: do_image_oci reports success,
>   but the layer's opkg/rpm install never actually installs anything,
>   because the per-layer package manager's local index/cache was never
>   refreshed after write_index() (do_rootfs itself always calls
>   pm.update() between the two; image-oci's per-layer installer
>   skipped it). The failure is only visible as a bb.warn(), so the
>   build looks green while shipping an empty (or partial) layer.

Aha. Since I've obviously tested the package installs and they work,
but multi layer is something that I don't recall testing in that combinatio=
n.

>
>   Reproduced with a minimal recipe (base-files+coreutils in a
>   "packages:" layer): before the fix, the resulting OCI layer blob
>   contains 0 regular files; after the fix, the same layer contains
>   272 files and the compressed blob grows from 299 bytes to 7.5 MB.
>   Full before/after evidence in the patch commit message and in
>   TEST-CASES.md if you'd like to reproduce it independently.
>

I'd definitely want to see a reproducer, both so I can confirm how
I didn't see this before, and so I can get it into the layer tests.

Does this same image reproduce the second issue as well ?
I'd also like to reproduce that, to hunt around and see if there's
any other options to resolve the problem.

Bruce

> 2/2 - image-oci: drop *-initial sysroot deps in do_image_oci to avoid
>       libgcc collision
>
>   do_image_oci can abort with:
>     ERROR: <recipe> do_image_oci: The file .../crtbegin.o is installed
>     by both libgcc and libgcc-initial, aborting
>
>   Root cause is in extend_recipe_sysroot's dependency walk: the
>   SSTATE_EXCLUDEDEPS_SYSROOT exclusion that normally keeps libgcc and
>   libgcc-initial from landing in the same sysroot only applies when
>   the *consuming* task is itself do_populate_sysroot. do_image_oci
>   reaches extend_recipe_sysroot through the generic "any task whose
>   [depends] contains populate_sysroot gets this prefunc" path
>   (staging_taskhandler), so that exclusion never fires for it.
>
>   This one is sstate-state-dependent -- whether it fires depends on
>   whether extend_recipe_sysroot's walk actually needs to populate (vs.
>   skip via sstate/setscene shortcuts) both libgcc and libgcc-initial
>   for a given recipe/build. A minimal single-package OCI recipe did
>   not reach libgcc in our testing, but a multi-layer "packages:" recipe
>   installing a from-source-compiled library with a moderately large
>   DEPENDS (boost) did: instrumenting the fix confirms it stripping two
>   "*-initial" do_populate_sysroot nodes out of BB_TASKDEPDATA for that
>   recipe, i.e. libgcc-initial is a real, reachable node in
>   do_image_oci's dependency walk for realistic recipes. We were not
>   able to force the raw abort deterministically within our test
>   window (a downstream build did hit it deterministically across 6+
>   clean-sstate attempts on a wider dependency set) -- see the patch
>   commit message and TEST-CASES.md for exactly what was and wasn't
>   reproduced, and why the fix is justified regardless.
>
>
> Signed-off-by: Koen Kooi <[email protected]>
>
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
> Links: You receive all messages sent to this group.
> View/Reply Online (#9990): https://lists.yoctoproject.org/g/meta-virtuali=
zation/message/9990
> Mute This Topic: https://lists.yoctoproject.org/mt/120482430/1050810
> Group Owner: [email protected]
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [=
[email protected]]
> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II