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 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.

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/78d27f6a-bdec-49fb-a600-7a877c151084%40siemens.com.