Bug 14748

Summary: runqemu can't pick bundled initramfs image
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Alejandro <alejandro>
Component: Scripts and ToolsAssignee: Jagadeesh Krishnanjanappa <workjagadeesh>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: pavel, randy.macleod, ross.burton, workjagadeesh
Version: unspecified   
Target Milestone: 4.2 M2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Bug Depends on:    
Bug Blocks: 14749    
Attachments:
Description Flags
runqemu to boot bundled initramfs kernel image none

Description Alejandro 2022-03-01 18:29:09 UTC
When setting:

INITRAMFS_IMAGE = "core-image-minimal-initramfs"                                                                                           
INITRAMFS_IMAGE_BUNDLE= "1"

Two kernel images are created: Image-initramfs--foo and Image--foo

The Image is the default kernel (without initramfs) and the Image-initramfs contains a bundled initramfs in it.

However, after building an image with such conf, runqemu still picks the Image by default booting in a different flow than the one the user selected.

One has to manually pass the Image-initramfs file to runqemu so it boots properly, this should be done automatically by runqemu when INITRAMFS_IMAGE_BUNDLE= "1"
Comment 1 Jagadeesh Krishnanjanappa 2022-04-13 14:36:16 UTC
Created attachment 4857 [details]
runqemu to boot bundled initramfs kernel image
Comment 2 Jagadeesh Krishnanjanappa 2022-04-13 14:37:40 UTC
The attached patch ([runqemu_14748.patch|https://bugzilla.yoctoproject.org/attachment.cgi?id=4857&action=diff]) picks the bundled initramfs kernel image (e.g., Image-initramfs-qemux86-64.bin) if INITRAMFS_IMAGE_BUNDLE is set to 1 in config files.

Let me know if this fixes the issue. If yes, then I will submit for review/commit.

Regards,
Jagadeesh
Comment 3 Jagadeesh Krishnanjanappa 2022-04-16 03:59:00 UTC
Hi Alejandro,

By any chance did you try the attached patch?

Regards,
Jagadeesh
Comment 4 Randy MacLeod 2022-10-27 13:57:59 UTC
 Alejandro, By any chance did you try the attached patch?
Comment 5 Randy MacLeod 2022-12-08 16:10:52 UTC
Pavel is going to check the patch.
Comment 6 Alejandro 2022-12-08 18:29:42 UTC
To give some context:
- No the provided patch doesnt work.

- The patch successfully sets QB_DEFAULT_KERNEL (although it has an extra .bin in it), and this QB_DEFAULT_KERNEL variable is written properly to the qemuboot.conf file, e.g.:

```
[config_bsp]                                                                                         
deploy_dir_image = .                                                                                 
image_link_name = core-image-minimal-qemuarm64                                                       
image_name = core-image-minimal-qemuarm64-20221129175938                                             
kernel_imagetype = Image                                                                             
machine = qemuarm64                                                                                                     
qb_default_fstype = ext4                                                                             
qb_default_kernel = Image-initramfs-qemuarm64
```

However, `runqemu` does not seem to pick up the kernel using QB_DEFAULT_KERNEL

```
$ runqemu nographic
runqemu - INFO - Running bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: builds/qemuarm64/tmp/deploy/images/qemuarm64/Image]
MACHINE: [qemuarm64]
```

It seems that runqemu specifically grabs the KERNEL_IMAGETYPE variable while starting up:

kernel_match_name = "%s/%s" % (deploy_dir_image, kernel_name)                            
kernel_match_link = "%s/%s" % (deploy_dir_image, self.get('KERNEL_IMAGETYPE'))                       kernel_startswith = "%s/%s*" % (deploy_dir_image, self.get('KERNEL_IMAGETYPE'))          
cmds = (kernel_match_name, kernel_match_link, kernel_startswith)
self.kernel = get_first_file(cmds)


The problem is actually that get_first_file function call:
It makes a choice between:
- Image-initramfs-qemuarm64
- Image
- Image*

Since the Image file exists as well, it prefers to use that one instead of Image-initramfs-<machine>
Comment 7 Jagadeesh Krishnanjanappa 2022-12-10 03:35:40 UTC
Just want to add clarifications on the previous pacth.

For qemux86-64, after applying the patch I added the following lines
in the conf/local.conf file and built the Linux kernel recipe.

INITRAMFS_IMAGE = "core-image-minimal-initramfs"                                      
IMAGE_FSTYPES:append = " ext4"
INITRAMFS_IMAGE_BUNDLE= "1"


Ran "runqemu nographic" and verified that the runqemu script 
is picking the initramfs bzImage while booting.
---
runqemu - INFO - Running bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [.../poky_master/build/tmp/deploy/images/qemux86-64/bzImage-initramfs-qemux86-64.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: [.../poky_master/build/tmp/deploy/images/qemux86-64/core-image-minimal-initramfs-qemux86-64-20221210031718.ext4]
CONFFILE: [.../poky_master/build/tmp/deploy/images/qemux86-64/core-image-minimal-initramfs-qemux86-64-20221210031718.qemuboot.conf]
--

Also, in the check_kernel() function, the get_first_file() is
called with the following 3 arguments at line 744, and get_first_file() takes
the file that is first found.


 732         # QB_DEFAULT_KERNEL is always a full file path
 733         kernel_name = os.path.basename(self.get('QB_DEFAULT_KERNEL'))
 734
 735         # The user didn't want a kernel to be loaded
 736         if kernel_name == "none" and not self.kernel:
 737             return
 738
 739         deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
 740         if not self.kernel:
 741             kernel_match_name = "%s/%s" % (deploy_dir_image, kernel_name)
 742             kernel_match_link = "%s/%s" % (deploy_dir_image, self.get('KERNEL_IMA     GETYPE'))
 743             kernel_startswith = "%s/%s*" % (deploy_dir_image, self.get('KERNEL_IM     AGETYPE'))
 744             cmds = (kernel_match_name, kernel_match_link, kernel_startswith)
 745             self.kernel = get_first_file(cmds)

In line 741 kernel_name is assigned with QB_DEFAULT_KERNEL value that is
${KERNEL_IMAGETYPE}-${INITRAMFS_LINK_NAME}.bin (bzImage-initramfs-qemux86-64.bin).

The above information is found for qemux86-64 and I am yet to try qemuarm64.

Regards,
Jagadeesh
Comment 8 Jagadeesh Krishnanjanappa 2022-12-11 14:18:07 UTC
Same behavior is observed with qemuarm64.

-- snip --
runqemu - INFO - Running bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [.../poky_master/build/tmp/deploy/images/qemuarm64/Image-initramfs-qemuarm64.bin]
MACHINE: [qemuarm64]
FSTYPE: [ext4]
ROOTFS: [.../poky_master/build/tmp/deploy/images/qemuarm64/core-image-minimal-initramfs-qemuarm64-20221210164439.ext4]
CONFFILE: [.../poky_master/build/tmp/deploy/images/qemuarm64/core-image-minimal-initramfs-qemuarm64-20221210164439.qemuboot.conf]

-- snip --

Regards,
Jagadeesh
Comment 9 Alejandro 2022-12-12 17:23:16 UTC
I just tested this again and it seems that you are right, I think the confusing part was the extra ".bin" which is inconsistent between the Image link and the Image-initramfs link (the Image link doesnt have it, but the Image-initramfs link does), either way I had manually removed that from the patch and all the flow was exactly the same, the only difference was the the get_first_file() function wouldn't return the Image-initramfs link (since it needed the .bin)

It seems to be working for me, I apologize for the confusion:
$ runqemu nographic                                                                                                                 runqemu - INFO - Running bitbake -e ...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [poky/builds/qemuarm64/tmp/deploy/images/qemuarm64/Image-initramfs-qemuarm64.bin]
MACHINE: [qemuarm64]
FSTYPE: [ext4]
ROOTFS: [poky/builds/qemuarm64/tmp/deploy/images/qemuarm64/core-image-minimal-qemuarm64-20221212171948.rootfs.ext4]
Comment 10 Jagadeesh Krishnanjanappa 2022-12-13 15:04:22 UTC
Taking the bug.

Alejandro,

No worries.

I just pushed the patch for review and merge in the OE-core mailing list.

Regards,
Jagadeesh
Comment 12 Jagadeesh Krishnanjanappa 2022-12-21 15:43:34 UTC
Should be resolved with https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=52371624313184e1a825519160c3833e282df8b9

Thanks,
Jagadeesh