15525 2024-06-21 08:48:02 +0000 Sometimes wrong kernel selected on QEmu when bundling an InitRamFS 2025-06-05 15:27:00 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 5.0 x86 Multiple RESOLVED FIXED Medium normal 5.2 1 Pascal.Weisser.ext Pascal.Weisser.ext meta.mr.watcher meta.watcher Pascal.Weisser.ext randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 99241 0 Pascal.Weisser.ext 2024-06-21 08:48:02 +0000 Hi, we're having an issue when using QEmu and an InitRamFS bundled into the kernel. We're using the following additional lines in local.conf: INITRAMFS_IMAGE_BUNDLE = "1" INITRAMFS_IMAGE = "core-image-minimal-initramfs" When we build the core-image-full-cmdline image the first time everything works as expected. But when we make a change in a script of the initramfs-framework which is packaged into the InitRamFS afterwards and build again the wrong kernel is selected (the kernel without the InitRamFS). I think the reason is the following: When building the first time the file core-image-full-cmdline-qemux86-64.rootfs.qemuboot.conf is poining to contains a line like this: qb_default_kernel = bzImage-initramfs--6.6.23+git0+f7f00b22ef_2d01bc1d4e-r0-qemux86-64-20240614132425.bin The reason is that the realpath instead of the symlink is written to the qemuboot.conf file [1]. When a change is made to a script of the initramfs-framework the core-image-minimal-initramfs is built again and bundled into the kernel. That creates a new kernel and the previous kernel referenced in the qemuboot.conf file of the core-image-full-cmdline image won't exist anymore. The qemuboot.conf file isn't adapted to that change. When starting QEmu the qemuboot.conf file is evaluated. Since the kernel referenced by qb_default_kernel doesn't exist QEmu falls back to a kernel whose name is starting with bzImage. In our case a kernel that doesn't contain the InitRamFS is selected. As the realpath of the kernel symlink is used as value for qb_default_kernel instead of the value of QB_DEFAULT_KERNEL itself a solution might be to make the do_write_qemuboot_conf task dependent on all variables that go into the value for qb_default_kernel which is written to qemuboot.conf. That way, the qemuboot.conf would be recreated when the realpath of the file QB_DEFAULT_KERNEL points to changes. This issue might be related to https://bugzilla.yoctoproject.org/show_bug.cgi?id=14520. [1]: https://git.yoctoproject.org/poky/tree/meta/classes-recipe/qemuboot.bbclass#n176 99277 1 randy.macleod 2024-06-27 14:38:59 +0000 You are on the right track with adding the missing dependencies variables. Can you continue with that and send a patch to the email list or ask for help there if you get stuck? 99312 2 Pascal.Weisser.ext 2024-07-03 10:59:24 +0000 I've submitted a patch today to the openembedded-core@lists.openembedded.org mailing list. 100088 3 randy.macleod 2024-10-31 15:09:23 +0000 Bulk move of 5.1 bugs to 5.2. -- YP bug review (Randy) 102165 4 randy.macleod 2025-06-05 15:27:00 +0000 ❯ git show 2e9e8f6fb3 commit 2e9e8f6fb3415f9aac6b5f96e8e7c8d9ced5beb5 Author: Weisser, Pascal.ext <Pascal.Weisser.ext@karlstorz.com> Date: Wed Jul 3 06:56:03 2024 qemuboot: Trigger write_qemuboot_conf task on changes of kernel image realpath The qemuboot.conf file contains the realpath of the kernel image referenced by QB_DEFAULT_KERNEL. So, it must be recreated in case the realpath of the referenced kernel image changes. The variables KERNEL_IMAGE_NAME and KERNEL_IMAGE_BIN_EXT determine the realpath of the kernel image relative to DEPLOY_DIR_IMAGE. Adding both of them to the vardeps of the write_qemuboot_conf task triggers the write_qemuboot_conf task in case the realpath of the kernel image referenced by QB_DEFAULT_KERNEL changes. Fixes: [YOCTO 15525] (From OE-Core rev: f8b3975a9ce36ea7af5fd76243a823da2842415b)