[PATCH 0/3] Resolve YOCTO #14520 and YOCTO #15525.

[PATCH 0/3] Resolve YOCTO #14520 and YOCTO #15525.

[Weisser, Pascal]

This patch series resolves the issues YOCTO #14520 and YOCTO #15525.

Weisser, Pascal (3):
  Revert "qemuboot: Trigger write_qemuboot_conf task on changes of
    kernel image realpath"
  qemuboot: Trigger do_write_qemuboot_conf task on bundled initramfs
    changes
  qemuboot: Provide default value for INITRAMFS_LINK_NAME

 meta/classes-recipe/qemuboot.bbclass | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.48.1

[PATCH 1/3] Revert "qemuboot: Trigger write_qemuboot_conf task on changes of kernel image realpath"

[Weisser, Pascal]

This reverts commit f8b3975a9ce36ea7af5fd76243a823da2842415b.

It was the wrong fix for YOCTO 15525 since the variables KERNEL_IMAGE_NAME and
KERNEL_IMAGE_BIN_EXT have the wrong values in an image recipe. Additionally,
new QB_ prefixed variables were introduced in the resulting configuration file
which had no meaning.

Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com>
---
 meta/classes-recipe/qemuboot.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes-recipe/qemuboot.bbclass b/meta/classes-recipe/qemuboot.bbclass
index 0f80c60ab5..895fd38d68 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -129,8 +129,7 @@ addtask do_write_qemuboot_conf after do_rootfs before do_image
 
 def qemuboot_vars(d):
     build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
-                'KERNEL_IMAGETYPE', 'KERNEL_IMAGE_NAME',
-                'KERNEL_IMAGE_BIN_EXT', 'IMAGE_NAME', 'IMAGE_LINK_NAME',
+                'KERNEL_IMAGETYPE', 'IMAGE_NAME', 'IMAGE_LINK_NAME',
                 'STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE',
                 'STAGING_DIR_HOST', 'SERIAL_CONSOLES', 'UNINATIVE_LOADER']
     return build_vars + [k for k in d.keys() if k.startswith('QB_')]
-- 
2.48.1

[PATCH 2/3] qemuboot: Trigger do_write_qemuboot_conf task on bundled initramfs changes

[Weisser, Pascal]

This change is needed for several reasons:

First, the do_write_qemuboot_conf task needs to access the deployed kernel
symbolic link in DEPLOY_DIR_IMAGE for determining its real path. If the
kernel symbolic link isn't already deployed, its real path cannot be
determined.

Second, an initramfs might be embedded into the kernel. Making changes to
the initramfs doesn't necessarily trigger the do_rootfs task of the file
system that includes the kernel but it triggers the do_deploy task of the
kernel. In order to trigger the do_write_qemuboot_conf task in this case,
too, we need the dependency on the virtual/kernel:do_deploy task.

When the do_write_qemuboot_conf task is triggered, we do not necessarily
need to create a new image, thus, we only demand the task to be executed
before the do_image_complete task.

Fixes: [YOCTO #14520]
Fixes: [YOCTO #15525]

Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com>
---
 meta/classes-recipe/qemuboot.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/qemuboot.bbclass b/meta/classes-recipe/qemuboot.bbclass
index 895fd38d68..163c4085ee 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -125,7 +125,7 @@ QB_DRIVE_TYPE ?= "/dev/sd"
 inherit image-artifact-names
 
 # Create qemuboot.conf
-addtask do_write_qemuboot_conf after do_rootfs before do_image
+addtask do_write_qemuboot_conf after do_rootfs before do_image_complete
 
 def qemuboot_vars(d):
     build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
@@ -134,6 +134,7 @@ def qemuboot_vars(d):
                 'STAGING_DIR_HOST', 'SERIAL_CONSOLES', 'UNINATIVE_LOADER']
     return build_vars + [k for k in d.keys() if k.startswith('QB_')]
 
+do_write_qemuboot_conf[depends] += "virtual/kernel:do_deploy"
 do_write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
 do_write_qemuboot_conf[vardepsexclude] += "TOPDIR"
 python do_write_qemuboot_conf() {
-- 
2.48.1

[PATCH 3/3] qemuboot: Provide default value for INITRAMFS_LINK_NAME

[Weisser, Pascal]

The qemuboot class uses the INITRAMFS_LINK_NAME variable which gets a
default value in the kernel-artifact-names class. Since that class inherits
from the image-artifact-names class we inherit from the
kernel-artifact-names class here, instead.

Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com>
---
 meta/classes-recipe/qemuboot.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/qemuboot.bbclass b/meta/classes-recipe/qemuboot.bbclass
index 163c4085ee..d51d1c454c 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -122,7 +122,7 @@ QB_KERNEL_CMDLINE_APPEND:append = " swiotlb=0"
 # This should be kept align with ROOT_VM
 QB_DRIVE_TYPE ?= "/dev/sd"
 
-inherit image-artifact-names
+inherit kernel-artifact-names
 
 # Create qemuboot.conf
 addtask do_write_qemuboot_conf after do_rootfs before do_image_complete
-- 
2.48.1

Re: [OE-core] [PATCH 0/3] Resolve YOCTO #14520 and YOCTO #15525.

[Mathieu Dubois-Briand]

On Tue Mar 18, 2025 at 11:48 AM CET, Pascal.ext via lists.openembedded.org Weisser wrote:
> This patch series resolves the issues YOCTO #14520 and YOCTO #15525.
>
> Weisser, Pascal (3):
>   Revert "qemuboot: Trigger write_qemuboot_conf task on changes of
>     kernel image realpath"
>   qemuboot: Trigger do_write_qemuboot_conf task on bundled initramfs
>     changes
>   qemuboot: Provide default value for INITRAMFS_LINK_NAME
>
>  meta/classes-recipe/qemuboot.bbclass | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Hi Pascal,

Thanks for your patch.

I believe this is creating circular dependencies in some cases: we got a
few errors on the autobuilder:

ERROR:
Dependency loop #1 found:
  Task /srv/pokybuild/yocto-worker/genericarm64-alt/build/meta/recipes-core/images/core-image-initramfs-boot.bb:do_image_complete (dependent Tasks ['qemu-system-native_9.2.0.bb:do_populate_sysroot', 'core-image-initramfs-boot.bb:do_image', 'core-image-initramfs-boot.bb:do_image_cpio', 'core-image-initramfs-boot.bb:do_write_qemuboot_conf', 'qemu-helper-native_1.0.bb:do_addto_recipe_sysroot'])
  Task /srv/pokybuild/yocto-worker/genericarm64-alt/build/meta/recipes-kernel/linux/linux-yocto_6.12.bb:do_bundle_initramfs (dependent Tasks ['core-image-initramfs-boot.bb:do_image_complete', 'linux-yocto_6.12.bb:do_install'])
  Task /srv/pokybuild/yocto-worker/genericarm64-alt/build/meta/recipes-kernel/linux/linux-yocto_6.12.bb:do_deploy (dependent Tasks ['depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'linux-yocto_6.12.bb:do_populate_sysroot', 'linux-yocto_6.12.bb:do_packagedata', 'pigz_2.8.bb:do_populate_sysroot', 'linux-yocto_6.12.bb:do_bundle_initramfs'])
  Task /srv/pokybuild/yocto-worker/genericarm64-alt/build/meta/recipes-core/images/core-image-initramfs-boot.bb:do_write_qemuboot_conf (dependent Tasks ['linux-yocto_6.12.bb:do_deploy', 'core-image-initramfs-boot.bb:do_rootfs'])

https://autobuilder.yoctoproject.org/valkyrie/#/builders/22/builds/1218
https://autobuilder.yoctoproject.org/valkyrie/#/builders/60/builds/1215

Can you have a look at these failures please?

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 0/3] Resolve YOCTO #14520 and YOCTO #15525

[Weisser, Pascal.ext]

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

Hi,

the problem arises because the dependency on virtual/kernel is added to the initramfs-image image, too, leading to a circular dependency loop. In our setup the problem didn't occur because we're building the initramfs-image in a different multi-configuration. That way the kernel depends on the initramfs-image from a different multi-configuration and no circular dependency loop is created.

To fix the issue we'd need a way to add the dependency on virtual/kernel to the do_write_qemuboot_conf task only only if we're not building an initramfs-image. But I have no idea at the moment how we could distinguish that case? Are there any ideas on that?

Best regards
Pascal

[-- Attachment #2: Type: text/html, Size: 791 bytes --]