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

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

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?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
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/a5f19b99-70e1-4ccb-af6e-bdd7fb072970%40siemens.com.