Bug 10717 - KERNEL_IMAGE_BASE_NAME: morty definition does not match poky's code
Summary: KERNEL_IMAGE_BASE_NAME: morty definition does not match poky's code
Status: RESOLVED FIXED
Alias: None
Product: Reference
Classification: Documentation
Component: handbook (show other bugs)
Version: 2.2
Hardware: All Multiple
: Medium normal
Target Milestone: 2.3 M4
Assignee: Joe Konno
QA Contact:
URL:
Whiteboard: 31 Jan 2017: NEEDINFO
Depends on:
Blocks:
 
Reported: 2016-11-23 21:44 UTC by Joe Konno
Modified: 2017-04-07 16:39 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Done (doc changes complete)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Konno 2016-11-23 21:44:52 UTC
See: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-KERNEL_IMAGE_BASE_NAME

In the Morty/2.2 release, there were changes make to poky (kernel.bbclass), to KERNEL_IMAGE_BASE_NAME and the handling thereof, that don't match up with the reference guide for Morty. Specifically by KERNEL_IMAGE_BASE_NAME, but I'll let those more knowledgeable speak to greater impact of those changes (if there are any).

With commit 0437a59e3c29 ("kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time"), handling for building multiple kernel image types was added. This new feature effectively changed the definition and application of KERNEL_IMAGE_BASE_NAME (and at least one other var):

-KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"                                             
+KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"

As of this change, the Morty documentation is no longer accurate for the variable.

I maintain a local bitbake recipe for the kernel, which copies the kernel config to DEPLOYDIR. My do_deploy changes, which had worked for krogoth, became problematic because of:

  KERNEL_IMAGE_BASE_NAME="-4.9-rc6+gitAUTOINC+<...snip...>"

instead of what I expected per the documentation, which ought to be:

  KERNEL_IMAGE_BASE_NAME="bzImage--4.9-rc6+gitAUTOINC+<...snip...>"

Inspecting the code, I do have a work-around. I had to re-use this pattern, adapted to my purposes:

<snip>
    install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin                                                         
    for type in ${KERNEL_IMAGETYPES} ; do                                                                                               
        base_name=${type}-${KERNEL_IMAGE_BASE_NAME}                                                                                 
        install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} ${DEPLOYDIR}/${base_name}.bin                                                  
    done
</snip>
Comment 1 Scott Rifenbark 2016-11-29 03:01:35 UTC
Hi Joe, 

So I have made updates to two places: the variable description itself and the migration section.  

See http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-KERNEL_IMAGE_BASE_NAME for the variable description change.

See http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#migration-2.2-kernel-image-base-name-no-longer-uses-kernel-imagetype for the new entry in the migration section.

The above changes are in the master branch of the yocto-docs repository.  I will back port them into the yocto-docs/morty branch so that they are on the tip of that development branch for the documentation.  You can see the changes there using the same two URLs above except with "2.2" as part of the URL and not "2.3".

Thanks,
Scott
Comment 2 Scott Rifenbark 2017-01-31 16:33:28 UTC
Needs review.  I moved to 2.3 M3.
Comment 3 Scott Rifenbark 2017-03-27 19:43:13 UTC
Moved to 2.3 M4... still needs a review.
Comment 4 Joe Konno 2017-04-03 19:57:10 UTC
Thanks Scott. Looks good to me. I'll go ahead and "resolve" this-- I'll let someone more deeply invested in Yocto "close" this, if it looks good to them.
Comment 5 Scott Rifenbark 2017-04-03 20:20:13 UTC
Joe, 

Thanks for marking it RESOLVED after looking the fix.  I am going to put the doc flag to "Done" for the bug. 

Scott