qemuboot is added as a task like so[1]: addtask do_write_qemuboot_conf after do_rootfs before do_image This means do_write_qemuboot_conf is only run if do_rootfs is run, which isn't always the case. In my case I have been tweaking the initramfs and a new image was created but not a corresponding .qemuboot.conf file, which caused some frustration as runqemu was booting the old image. [1] https://git.openembedded.org/openembedded-core/tree/meta/classes/qemuboot.bbclass?id=4e9a06b64b43131b731fb59a0305f78a98e27fbd#n104
Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team.
Moved to M4.
Bulk move to 5.0 M1. -- Randy
Bulk move of 52 5.0-M1 bugs to M2.
Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.
Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone.
Kristian, Reviewing old bugs. Is this still a problem on the master branch ?
Quan please re-test.
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/qemuboot.bbclass#n130
Reproduced on current master (linux-yocto 6.18.33, core-image-minimal, qemux86-64). After rebuilding only the kernel (bitbake -c cleansstate linux-yocto), the .qemuboot.conf symlink retained the old timestamp while ext4.zst was updated to a new one. Fix: add do_write_qemuboot_conf[depends] += "${KERNEL_DEPLOY_DEPEND}" KERNEL_DEPLOY_DEPEND is already used by do_build[depends] in image.bbclass for the same reason and handles firmware/baremetal images since it is defined with ?=. v2 patch submitted to openembedded-core mailing list: https://lists.openembedded.org/g/openembedded-core/topic/patch_v2_qemuboot_bbclass/119596210
v3 patch submitted fixing the autobuilder failure reported on v2. Root cause: baremetal images inherit qemuboot via baremetal-image.bbclass but do not set KERNEL_DEPLOY_DEPEND, causing a parse error when empty string was passed to [depends]. Fix uses a Python expression to guard against the empty case: do_write_qemuboot_conf[depends] += "${@d.getVar('KERNEL_DEPLOY_DEPEND') or ''}" Tested: - do_write_qemuboot_conf reruns correctly after kernel rebuild on qemux86-64 - 949 recipes parse cleanly with MACHINE=qemuarm, no errors v3 patch: https://lists.openembedded.org/g/openembedded-core/topic/patch_v3_qemuboot_bbclass/119609347
v4 patch submitted fixing the circular dependency reported on v3. Root cause of circular dependency: when INITRAMFS_IMAGE_BUNDLE=1, linux-yocto:do_deploy depends on the initramfs image completing first, so adding an unconditional kernel deploy dependency on do_write_qemuboot_conf created a cycle back into the initramfs image. Fix skips the kernel deploy dependency when INITRAMFS_IMAGE_BUNDLE=1: do_write_qemuboot_conf[depends] += "${@ '' if bb.utils.to_boolean(d.getVar('INITRAMFS_IMAGE_BUNDLE')) else (d.getVar('KERNEL_DEPLOY_DEPEND') or '')}" Tested: - do_write_qemuboot_conf reruns correctly after kernel rebuild on qemux86-64 - 949 recipes parse cleanly with MACHINE=qemuarm, no errors - bitbake -g with INITRAMFS_IMAGE_BUNDLE=1 confirms no circular dependency https://lists.openembedded.org/g/openembedded-core/topic/patch_v4_qemuboot_bbclass/119770767
Thanks for working on this Siva. Quan isn't available right now so assigning to you.
Thank you Randy. I will monitor v4 on the mailing list and address any further review comments promptly.
https://git.openembedded.org/openembedded-core/commit/?id=ed97056104ed2b97a687f956b49be7241862be53