[yocto] 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
Hello @all, because I need the commit 'dcadeda' I switched from denzil to 1.3_M3. Now I get a strage error while do_kernel_config: | configme --reconfig --output .../linux-portuxg20-standard-build standard stamp9g20 | [INFO] Configuring target/machine combo: standard/stamp9g20 | [INFO] collecting configs in ./meta/meta-series | [##] (completed in 0 seconds) | ERROR: could not sanitize configuration fragments |errors are logged in meta/cfg/standard/portuxg20/config.log Digin a bit deeper I found: | [INFO] Sanitizing meta/cfg/kernel-cache/features/fuse/fuse.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/ktypes/standard/standard.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/devtmpfs.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/debugfs.cfg | [INFO] Sanitizing meta/cfgportuxg20 ^ | [ERROR] Kern frag does not exist And again a bit deeper I found that the file | ./meta/cfg/standard/portuxg20/config_frag.txt is somewhat crippled: | ... | /kernel-cache/ktypes/standard/standard.cfg | /kernel-cache/cfg/devtmpfs.cfg | /kernel-cache/cfg/debugfs.cfg | portuxg20 ^ | hardware.cfg | non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | portuxg20 | hardware.cfg | non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | /hardware.cfg | /non-hardware.cfg | /portuxg20/portuxg20.cfg | /kernel-cache/features/netfilter/netfilter.cfg | /kernel-cache/features/taskstats/taskstats.cfg Who is creating this file? Cheers, Markus -- Human beings were created by water to transport it uphill. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
On 12-08-23 09:24 AM, Markus Hubig wrote: Hello @all, because I need the commit 'dcadeda' I switched from denzil to 1.3_M3. Now I get a strage error while do_kernel_config: | configme --reconfig --output.../linux-portuxg20-standard-build standard stamp9g20 | [INFO] Configuring target/machine combo: standard/stamp9g20 | [INFO] collecting configs in ./meta/meta-series | [##] (completed in 0 seconds) | ERROR: could not sanitize configuration fragments |errors are logged in meta/cfg/standard/portuxg20/config.log Digin a bit deeper I found: | [INFO] Sanitizing meta/cfg/kernel-cache/features/fuse/fuse.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/ktypes/standard/standard.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/devtmpfs.cfg | [INFO] Sanitizing meta/cfg/kernel-cache/cfg/debugfs.cfg | [INFO] Sanitizing meta/cfgportuxg20 ^ | [ERROR] Kern frag does not exist And again a bit deeper I found that the file | ./meta/cfg/standard/portuxg20/config_frag.txt is somewhat crippled: | ... | /kernel-cache/ktypes/standard/standard.cfg | /kernel-cache/cfg/devtmpfs.cfg | /kernel-cache/cfg/debugfs.cfg | portuxg20 ^ | hardware.cfg | non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | portuxg20 | hardware.cfg | non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | /hardware.cfg | /non-hardware.cfg | /portuxg20/portuxg20.cfg | /kernel-cache/features/netfilter/netfilter.cfg | /kernel-cache/features/taskstats/taskstats.cfg Who is creating this file? Were you using yocto-bsp to create the BSP framework ? I did some test builds of the layer you previously sent me, and I didn't reproduce the problem, but this is the same thing that you had seen last week. Do you have an updated layer that I can try against master ? Bruce Cheers, Markus ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote: On 12-08-23 09:24 AM, Markus Hubig wrote: snipp And again a bit deeper I found that the file | ./meta/cfg/standard/portuxg20/config_frag.txt is somewhat crippled: | ... | /kernel-cache/ktypes/standard/standard.cfg | /kernel-cache/cfg/devtmpfs.cfg | /kernel-cache/cfg/debugfs.cfg | portuxg20 ^ That was a typo. Fixed! | hardware.cfg | non-hardware.cfg These files were living in meta-stamp9g20/recipes-kernel/files | /kernel-cache/features/usb-net/usb-net.cfg | portuxg20 | hardware.cfg | non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg Here we have the same thing a second time. | /hardware.cfg | /non-hardware.cfg | /portuxg20/portuxg20.cfg And a third time, but with a correct path. After changing my BSP-Kernel layout from: | ▾ recipes-kernel/ | ▾ linux/ | ▾ files/ | hardware.cfg | non-hardware.cfg | ▾ portuxg20/ | portuxg20-preempt-rt.scc | portuxg20-standard.scc | portuxg20.cfg | portuxg20.scc | ▾ stamp9g20/ | stamp9g20-preempt-rt.scc | stamp9g20-standard.scc | stamp9g20.cfg | stamp9g20.scc To this: | ▾ recipes-kernel/ | ▾ linux/ | ▾ files/ | ▾ portuxg20/ | hardware.cfg | non-hardware.cfg | portuxg20-preempt-rt.scc | portuxg20-standard.scc | portuxg20.cfg | portuxg20.scc | ▾ stamp9g20/ | hardware.cfg | non-hardware.cfg | stamp9g20-preempt-rt.scc | stamp9g20-standard.scc | stamp9g20.cfg | stamp9g20.scc and using | SRC_URI_append_portuxg20 = \ | file://portuxg20-standard.scc \ | file://portuxg20-preempt-rt.scc \ | file://portuxg20.scc\ | file://portuxg20.cfg\ | file://hardware.cfg \ | file://non-hardware.cfg \ | | | SRC_URI_append_stamp9g20 = | file://stamp9g20-standard.scc \ | file://stamp9g20-preempt-rt.scc \ | file://stamp9g20.scc\ | file://stamp9g20.cfg\ | file://hardware.cfg \ | file://non-hardware.cfg \ | instead of this: | SRC_URI += \ | file://hardware.cfg \ | file://non-hardware.cfg \ | | | SRC_URI_append_portuxg20 = \ | file://portuxg20-standard.scc \ | file://portuxg20-preempt-rt.scc \ | file://portuxg20.scc\ | file://portuxg20.cfg\ | | | SRC_URI_append_stamp9g20 = | file://stamp9g20-standard.scc \ | file://stamp9g20-preempt-rt.scc \ | file://stamp9g20.scc\ | file://stamp9g20.cfg\ | I get this config_frag.txt but at the cost of duplicating the hardware.cfg and non-hardware.cfg files. | /kernel-cache/ktypes/base/base.cfg | /kernel-cache/features/kgdb/kgdb.cfg | /kernel-cache/features/lttng/lttng.cfg | /kernel-cache/features/blktrace/blktrace.cfg | /kernel-cache/features/systemtap/systemtap.cfg | /kernel-cache/features/utrace/utrace.cfg | /kernel-cache/arch/arm/arm.cfg | /kernel-cache/features/hrt/hrt.cfg | /kernel-cache/features/ftrace/ftrace.cfg | /kernel-cache/features/unionfs/unionfs.cfg | /kernel-cache/features/cgroups/cgroups.cfg | /kernel-cache/features/namespaces/namespaces.cfg | /kernel-cache/features/namespaces/namespaces-experimental.cfg | /kernel-cache/features/fuse/fuse.cfg | /kernel-cache/ktypes/standard/standard.cfg | /kernel-cache/cfg/devtmpfs.cfg | /kernel-cache/cfg/debugfs.cfg | /portuxg20/portuxg20.cfg | /portuxg20/hardware.cfg | /portuxg20/non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | /portuxg20/portuxg20.cfg | /portuxg20/hardware.cfg | /portuxg20/non-hardware.cfg | /kernel-cache/features/usb-net/usb-net.cfg | /kernel-cache/features/netfilter/netfilter.cfg | /kernel-cache/features/taskstats/taskstats.cfg Whitch looks way better! And now I get this config check again: | This BSP sets 2 invalid/obsolete kernel options. | These config options are not offered anywhere within this kernel. | The full list can be found in your kernel src dir at: | meta/cfg/standard/portuxg20/invalid.cfg | | This BSP sets 11 kernel options that are possibly non-hardware related. | The full list can be found in your kernel src dir at: | meta/cfg/standard/portuxg20/specified_non_hdw.cfg | | WARNING: There were 1 hardware options requested that do not | have a corresponding value present in the final .config file. | This probably means you aren't getting the config you wanted. | The full list can be found in your kernel src dir at: | meta/cfg/standard/portuxg20/mismatch.cfg | | Waiting a second to make sure you get a chance to see this... Surprisingly if I remove the *.cfg files from the SRC_URI |
Re: [yocto] 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
On Thu, Aug 23, 2012 at 12:26:30PM -0400, Bruce Ashfield wrote: On 12-08-23 12:18 PM, Markus Hubig wrote: On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote: On 12-08-23 09:24 AM, Markus Hubig wrote: snipp Surprisingly if I remove the *.cfg files from the SRC_URI | SRC_URI_append_portuxg20 = \ | file://portuxg20-standard.scc \ | file://portuxg20-preempt-rt.scc \ | file://portuxg20.scc\ | | | SRC_URI_append_stamp9g20 = | file://stamp9g20-standard.scc \ | file://stamp9g20-preempt-rt.scc \ | file://stamp9g20.scc\ it also works ... Yes, and I can explain this part. When a .scc file is detected, the entire directory contents are propagated to the kernel build, since .scc files can refer to patches, configs, etc, and some elements are optional, they are all made available. So if you reference .cfgs and patches in your .scc files, you don't need them in the SRC_URI, just the .scc file. Is it possible that if I remove the *.cfg files, bitbake no longer tracks changes inside this files and will not rebuild the related packages from scratch with: | bitbake -fc clean linux-yocto | bitbake linux-yocto Cheers, Markus -- Human beings were created by water to transport it uphill. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M3 do_kernel_config failes, config_frag.txt is crippled.
On 12-08-23 01:28 PM, Markus Hubig wrote: On Thu, Aug 23, 2012 at 12:26:30PM -0400, Bruce Ashfield wrote: On 12-08-23 12:18 PM, Markus Hubig wrote: On Thu, Aug 23, 2012 at 09:31:15AM -0400, Bruce Ashfield wrote: On 12-08-23 09:24 AM, Markus Hubig wrote: snipp Surprisingly if I remove the *.cfg files from the SRC_URI | SRC_URI_append_portuxg20 = \ | file://portuxg20-standard.scc \ | file://portuxg20-preempt-rt.scc \ | file://portuxg20.scc\ | | | SRC_URI_append_stamp9g20 = | file://stamp9g20-standard.scc \ | file://stamp9g20-preempt-rt.scc \ | file://stamp9g20.scc\ it also works ... Yes, and I can explain this part. When a .scc file is detected, the entire directory contents are propagated to the kernel build, since .scc files can refer to patches, configs, etc, and some elements are optional, they are all made available. So if you reference .cfgs and patches in your .scc files, you don't need them in the SRC_URI, just the .scc file. Is it possible that if I remove the *.cfg files, bitbake no longer tracks changes inside this files and will not rebuild the related packages from scratch with: If the checksums are over the elements in the SRC_URI, then that would be true, but I'm not a checksum or fetcher expert. repeating a .cfg really should be safe, just a bit verbose, I'll retest that here to see if something broke. My workflow never hits any problems with not rebuilding, but I can also check that. If necessary, listing the files, or another technique to get the checksum'd would be advisable. I'll look into that as well. Cheers, Bruce | bitbake -fc clean linux-yocto | bitbake linux-yocto Cheers, Markus ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
