Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Zhihang Wei <wzh@ilbers.de>]

On 4/8/26 15:10, Jan Kiszka wrote:
> On 07.04.26 16:29, Quirin Gylstorff wrote:
>> Hi,
>>
>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>> binaries to the deploy directory.
>>>
>>> When different images for the same target (e.g., "-base" and "-debug")
>>> are built in parallel, DTB deployment may fail because DTBs do not
>>> contain image-specific components in their filenames, unlike the kernel
>>> and initrd. As a result, artifacts from different builds may be written
>>> to the same location.
>>>
>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>> with names of distro image encoded to the path.
>>>
>>> Note that this results in separate copies of the same artifacts being
>>> deployed for each image build.
>>>
>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>> as a custom initrd is no longer part of the same directory structure as
>> the rest of the image. As the custom initramfs is a separate package it
>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>> imagetypes_wic.bbclass#L215.
>>
>> Also merge_wic_sbom does no longer work with a custom initrd.
>>
> The RECIPE-API-CHANGLOG says:
>
>> Artifacts that do not belong to a full image (e.g. isar-image-base,
>> isar-image-ci) remain unchanged. For example, a customized initramfs
>> built independently is not affected.
> And this is the problem: Customized initramfs logically belonged to full
> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
> but there also with the traditional image file naming, flat.
"remain unchanged" here means the customized initramfs keep the same
filenames and paths as before.

Customized initramfs are built by their own recipes. While building a
full image may trigger the build of a customized initramfs, they can
also be built separately. In contrast, the default initramfs is not a
standalone recipe but a task within the image build process. So
technically, customized initramfs are independent artifacts.

If CIP core associates a specific customized initramfs with an image
via DEPLOY_DIR_IMAGE, this assumption is affected by the new layout and
needs to be adapted accordingly.
> Quirin tried some isar-cip-core conversion, and this is the new
> deployment reality:
>
> build/tmp/deploy/images/qemu-amd64/
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
> └── cip-core-trixie-cip-core-image
>      ├── bootx64.efi
>      ├── linux.efi
>      ├── OVMF
>      │   ├── OVMF_CODE_4M.fd
>      │   ├── OVMF_CODE_4M.ms.fd
>      │   ├── OVMF_CODE_4M.secboot.fd
>      │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>      │   ├── OVMF_CODE_4M.snakeoil.fd
>      │   ├── OVMF_VARS_4M.fd
>      │   ├── OVMF_VARS_4M.ms.fd
>      │   └── OVMF_VARS_4M.snakeoil.fd
>      ├── qemu-amd64.cdx.json
>      ├── qemu-amd64.dpkg_status
>      ├── qemu-amd64-ebg.swu
>      ├── qemu-amd64.manifest
>      ├── qemu-amd64.spdx.json
>      ├── qemu-amd64.squashfs
>      ├── qemu-amd64.swu
>      ├── qemu-amd64.uuid.env
>      ├── qemu-amd64.wic
>      ├── qemu-amd64.wic.bmap
>      ├── qemu-amd64.wic.cdx.json
>      ├── qemu-amd64.wic.manifest
>      ├── qemu-amd64.wic.spdx.json
>      └── vmlinuz
>
> Already visually, this screams for improvements. But I'm afraid there
> are more concrete issues hidden in even more complex layers.
>
> And this is exactly why I strongly recommended to NOT merge these
> changes in a hurry before the release anymore. We already needed 9
> versions, and we were still not fully confident about the stability of
> the new solution.
If this kind of issue should be detected before merging, a CIP core
test case needs to be added to CI.

Zhihang
>
> Looks like we now need a 1.0.1, either with a really consistent approach
> or a revert. I would not recommend any downstreams affected by the
> deploy dir changes to jump on 1.0 until we sorted out all details.
>
> Jan
>

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/6a128eca-1346-4774-a1c0-139cae457956%40ilbers.de.