Re: [OE-core] [PATCH] uki.bbclass: fix building of UKI images with multiple initramfs fstypes

[Paul Barker <paul@pbarker.dev>]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Wed, 2026-01-07 at 06:23 +0200, Dmitry Baryshkov via
lists.openembedded.org wrote:
> If INITRAMFS_FSTYPES contains more than one entry, ukify build command
> will fail as INITRD_ARCHIVE will contain extra strings. Use only the
> first initramfs type, letting the user to specify other fstypes.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  meta/classes-recipe/uki.bbclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/uki.bbclass b/meta/classes-recipe/uki.bbclass
> index a2b1c8a82d6f..7457662f3f5e 100644
> --- a/meta/classes-recipe/uki.bbclass
> +++ b/meta/classes-recipe/uki.bbclass
> @@ -73,7 +73,8 @@ require ../conf/image-uefi.conf
>  
>  INITRAMFS_IMAGE ?= "core-image-minimal-initramfs"
>  
> -INITRD_ARCHIVE ?= "${INITRAMFS_IMAGE}-${MACHINE}.${INITRAMFS_FSTYPES}"
> +UKI_CPIO_FSTYPE ?= "${@d.getVar("INITRAMFS_FSTYPES").split()[0]}"
> +INITRD_ARCHIVE ?= "${INITRAMFS_IMAGE}-${MACHINE}.${UKI_CPIO_FSTYPE}"

Hi Dmitry, apologies for the delays in review.

The general idea here is ok but we would like to avoid additional
dynamic calls in variable assignments where we can - each time we add
some Python code in a variable assignment it slows down recipe parsing a
little further.

In this case, INITRD_ARCHIVE is only used in the do_uki() Python
function. Can move the parsing of INITRAMFS_FSTYPES into this function?
That would mean it only executes once during the do_uki task and not
during recipe parsing.

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]