| Summary: | eSDK fails to build for openbmc project | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] eSDK | Reporter: | Henry Bruce <henry.bruce> | ||||
| Component: | eSDK | Assignee: | Paul Eggleton <bluelightning> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | california.l.sullivan, david.j.cobbley, dl9pf | ||||
| Version: | 2.2 | ||||||
| Target Milestone: | 2.4 M4 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Attachments: |
|
||||||
|
Description
Henry Bruce
2017-04-06 20:53:21 UTC
So I think the issue - which I've realised we've seen elsewhere but not tracked down until now - is that we are generating an image and then that gets combined into a kernel "fitimage". Unfortunately the signature for the image changes with the date/time (possibly by inclusion of the os-release package), and thus the do_assemble_fitimage task gets re-triggered - but that requires the kernel work tree to be present, which means we have to extract and build it again, and the internal bitbake operation that we run as part of probing dependencies blocks that since otherwise the same failure would just happen later upon installation. At the moment I'm not quite sure what the correct solution to this is, but I at least have an idea of what's causing it. I have a workaround for the immediate issue, which is to set the following in the configuration:
SDK_TARGETS_append = " linux-obmc"
This isn't ideal as the kernel will be rebuilding as part of the eSDK installation process, but until we untangle the dependencies so we can avoid it thinking it needs to rebuild, this is the best available workaround I can think of.
Once that's applied there is another issue. In meta-phosphor/conf/distro/openbmc-phosphor.conf there is an INHERIT_remove = " uninative", which is very bad for the eSDK since it relies upon uninative and the installation will fail without it. The quick workaround of course is just to comment out this line. If you do need to do your normal builds without uninative and have it on only for the eSDK, you'd have to change openbmc-phosphor to *not* require conf/distro/poky.conf and just duplicate the bits it needs without inheriting uninative or requiring yocto-uninative.inc so that you don't have to use the INHERIT_remove. (Typically setting up your distro config as independent from poky.conf is what I would recommend anyway, regardless of whether you use uninative or not - then your distro config will only have the things you want in it and not what we deem appropriate to have in the poky reference distro at some point in future; ultimately it comes down to what you're trying to achieve I suppose.)
There's one other possible issue that I haven't verified, but I think if you have any recipes included that set SRCREV = "${AUTOREV}" then you'd need to set an explicit SRCREV for those. It so happens there is one in the layers, common/recipes-devtools/python/python-tftpy.bb, but I don't see any explicit references to it so maybe it's not being built by default. (This is probably something we should be handling automatically, I've filed bug 11350 to track that.)
We have recently done some work in this area under bug 12102. I just backported the patches that resolved that to openbmc and re-tested and they appear to have fixed the issue there also. Here are the backported patches: https://github.com/bluelightning/openbmc/tree/paule/esdk-initramfs-fix These are in poky/OE-Core master now for the upcoming 2.4 release and I have also sent backports for pyro, so I'm now marking this bug resolved. (Just one thing to keep in mind - you still need to drop the INHERIT_remove = " uninative" as noted above). |