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 09.04.26 17:35, Zhihang Wei wrote:
> 
> 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.

The problem is that Isar upstream lacks a realistic use case for
customized initramfs. One would be to embed it into a rootfs, as
replacement of the default one. Quirin had the idea of packaging it for
that. Another would be feeding it into the UKI generation of
bootimg-efi-isar but that has unfortunately not yet been enabled for Isar.

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

Unfortunately, this will need a process, not just a pipeline step
because breaking changes will need at least temporary patches to that layer.

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/f5026115-5c19-4535-8832-5dbc7f5b1a65%40siemens.com.