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:27 PM, Jan Kiszka wrote:
> On 08.04.26 15:20, Quirin Gylstorff wrote:
>>
>>
>> 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.
>>
> 
> You mean
> 
> cip-core-image.wic
> 
> rather than
> 
> qemu-amd64.wic
> 
> above, right?

Yes.

Also here is the current state in isar-cip-core 
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/qg/isar/update-to-1.0.

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/9a2851d9-7fc9-4951-bdff-e22a86ec3ed1%40siemens.com.