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

["'Quirin Gylstorff' via isar-users" <isar-users@googlegroups.com>]

On 4/8/26 3:10 PM, 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.
> 
> 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.
> 
> 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.

Why are we using now ${MACHINE}.* as identifier and not ${IMAGE_PN}. In 
a ci/cd script i prefer the IMAGE_PN as it shows me what I need to collect.

Quirin

> 
> 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/f9b6e995-6ca6-4abd-8f92-b35d62602ab0%40siemens.com.