Bug 11523

Summary: qemuboot.conf files in the downloads.../machines/qemu/qemu<machine> should be scrubbed of ab paths
Product: [Build System, Metadata & Runtime] OE-Core Reporter: brian avery <brian.avery>
Component: Scripts and ToolsAssignee: brian avery <brian.avery>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: brian.avery, chin.huat.ang, liezhi.yang, ross.burton
Version: 2.4   
Target Milestone: 2.4 M2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description brian avery 2017-05-18 00:37:01 UTC 
The <image>.qemuboot.conf has variables that point to the yocto-autobuilder paths of the image, deploy directory, etc.  Since these conf files are in the downloads dir, we should scrub them of the autobuilder specific language so that it is obvious they should be used with the downloadable images and kernels.

Why this matters: 
The qemuboot.conf for mips64-sato allows it to boot in qemu and have X work. Without the qemuboot.conf, you get a kernel panic from the wrong machine memory. If you force the correct memory size, you still get a blank X11 screen... 

If someone naively looks at the conf file, they are unlikely to use it for the downloaded images due to the many autobuilder paths in it.
Comment 1 Robert Yang 2017-07-13 08:49:08 UTC 
You've fixed it:

commit b2b422c190af482a0b4b7291545aa3239c15a1e8
Author: brian avery <brian.avery@intel.com>
Date:   Wed Apr 19 12:49:04 2017 -0700

    qemuboot.bbclass: save relative paths in conf file
    
    This saves relative paths in the qemuboot.conf file instead of absolute
    paths. This is to allow the images and kernels to be relocated and still
    have the testimage and runqemu work.
    
    [YOCTO #11375]
    
    (From OE-Core rev: 235243d7be5df57df4767e4710b846e83f0aa9fd)
    
    Signed-off-by: brian avery <brian.avery@intel.com>
    Signed-off-by: Ross Burton <ross.burton@intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>