On Tue, May 19, 2015 at 12:42 PM, Brian Hutchinson <b.hutch...@gmail.com> wrote: > On Tue, May 19, 2015 at 12:31 PM, Bruce Ashfield > <bruce.ashfi...@windriver.com> wrote: >> On 2015-05-19 07:39 AM, Bruce Ashfield wrote: >>> >>> On Fri, May 15, 2015 at 4:21 PM, Brian Hutchinson <b.hutch...@gmail.com> >>> wrote: >>>> >>>> On Fri, May 15, 2015 at 3:26 PM, Brian Hutchinson <b.hutch...@gmail.com> >>>> wrote: >>>>> >>>>> On Fri, May 15, 2015 at 9:55 AM, Brian Hutchinson <b.hutch...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On Thu, May 14, 2015 at 6:16 PM, Brian Hutchinson >>>>>> <b.hutch...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> On May 14, 2015 6:08 PM, "Denys Dmytriyenko" <de...@denix.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote: >>>>>>>>> >>>>>>>>> On 2015-05-12 10:20 AM, Brian Hutchinson wrote: >>>>>>>>>> >>>>>>>>>> On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield >>>>>>>>>> <bruce.ashfi...@windriver.com> wrote: >>>>>>>>>>> >>>>>>>>>>> On 2015-05-11 02:10 PM, Brian Hutchinson wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield >>>>>>>>>>>> <bruce.ashfi...@windriver.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is plausible. But in theory, linux-dummy should still provide >>>>>>>>>>>>> what you need (but since it doesn't build anything, there is >>>>>>>>>>>>> no abi .. and no modules can be built against it) .. so the >>>>>>>>>>>>> error isn't graceful. >>>>>>>>>>>>> >>>>>>>>>>>>> Bruce >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can confirm this same problem is happening to me. I just >>>>>>>>>>>> updated >>>>>>>>>>>> one of my builds from 1.7 to 1.8 and am also getting my rootfs to >>>>>>>>>>>> fail >>>>>>>>>>>> due to no abi kernel version: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We still have a race condition in the 1.8 branch for the >>>>>>>>>>> population >>>>>>>>>>> of the build-artifacts directory. >>>>>>>>>>> >>>>>>>>>>> If modules start building, they'll race against the population of >>>>>>>>>>> the >>>>>>>>>>> abiversion, and you may see that message. >>>>>>>>>>> >>>>>>>>>>> There's a proposed patch for master, but I don't think it is in >>>>>>>>>>> fido yet. >>>>>>>>>>> >>>>>>>>>>> Bruce >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Bruce, >>>>>>>>>> >>>>>>>>>> I did some searches and looks like there are a number of 'race' >>>>>>>>>> condition fixes but it wasn't obvious which one I may need. Is it >>>>>>>>>> this one: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> That's the one that should make sure that the shared workdir >>>>>>>>> (Which has the abiversion) is in place before building any modules. >>>>>>>>> >>>>>>>>> I can't say that it is exactly your issue, but it is the change >>>>>>>>> I was thinking of. >>>>>>>> >>>>>>>> >>>>>>>> Brian, >>>>>>>> >>>>>>>> Were you able to try the above mentioned commit against am180x in >>>>>>>> meta-ti? >>>>>>>> Did >>>>>>>> it solve the missing abi kernel version? Thanks. >>>>>>>> >>>>>>>> -- >>>>>>>> Denys >>>>>>> >>>>>>> >>>>>>> Hi Denys, >>>>>>> >>>>>>> No, I got caught up in something else ... I'll try it tomorrow and >>>>>>> report >>>>>>> back after I cherry pick that commit Bruce mentioned. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Brian >>>>>> >>>>>> >>>>>> Update. Not sure if I did this right but this is what I did. I added >>>>>> master as a remote and cherry picked >>>>>> 02d0a003d603266114512160b209876199241e98. Next I just went for it and >>>>>> tried to bitbake my image again and got the same result as before. >>>>>> Next I did a bitbake cleanall on virtual/kernel and tried to make my >>>>>> image again and still got the same result. >>>>>> >>>>>> I'm going to leave this build as is and setup a new one using 1.8 >>>>>> master and see if I get the same thing again. I'll leave this broken >>>>>> build alone for a while in case someone wants me to try something with >>>>>> it to fix it. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Brian >>>>> >>>>> >>>>> Yet another update ... I did a fresh checkout of master and tried to >>>>> build and had the same kernelabiversion error: >>>>> >>>>> WARNING: omap3-sgx-modules-5.01.01.01 ONLY supports hardfp mode for >>>>> now####################### >>>>> | ETA: >>>>> 00:00:28 >>>>> WARNING: omap3-sgx-modules-5.01.01.02 ONLY supports hardfp mode for now >>>>> WARNING: ti-cgt6x-8.0.0 ONLY supports hardfp mode for >>>>> now######################################## >>>>> >>>>> | ETA: 00:00:26 >>>>> Parsing recipes: 100% >>>>> >>>>> |##############################################################################################################################################################################| >>>>> Time: 00:01:02 >>>>> Parsing of 1802 .bb files complete (0 cached, 1802 parsed). 2303 >>>>> targets, 182 skipped, 0 masked, 0 errors. >>>>> NOTE: Resolving any missing task queue dependencies >>>>> NOTE: multiple providers are available for u-boot (u-boot, >>>>> u-boot-glsdk, u-boot-ti-staging) >>>>> NOTE: consider defining a PREFERRED_PROVIDER entry to match u-boot >>>>> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) >>>>> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg >>>>> >>>>> Build Configuration: >>>>> BB_VERSION = "1.27.0" >>>>> BUILD_SYS = "x86_64-linux" >>>>> NATIVELSBSTRING = "Debian-7.8" >>>>> TARGET_SYS = "arm-poky-linux-gnueabi" >>>>> MACHINE = "am180x-evm" >>>>> DISTRO = "poky" >>>>> DISTRO_VERSION = "1.8+snapshot-20150515" >>>>> TUNE_FEATURES = "arm armv5 thumb dsp" >>>>> TARGET_FPU = "soft" >>>>> meta >>>>> meta-yocto >>>>> meta-yocto-bsp = "master:fab7da4f8030a4067db0522f77eaa6d3b501c68f" >>>>> meta-ti = "master:60a7bfbf96609ef6f3e084c32b2af853222b3b7e" >>>>> meta-oe >>>>> meta-python >>>>> meta-networking >>>>> meta-webserver = "master:53d55216c8c721d3b66ec8f968737bf081def870" >>>>> >>>>> NOTE: Preparing RunQueue >>>>> NOTE: Executing SetScene Tasks >>>>> NOTE: Executing RunQueue Tasks >>>>> WARNING: QA Issue: /usr/bin/apxs_apache2-dev contained in package >>>>> apache2-dev requires /usr/bin/perl, but no providers found in its >>>>> RDEPENDS [file-rdeps] >>>>> ERROR: No kernel-abiversion file found >>>>> >>>>> (/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-abiversion), >>>>> cannot run depmod, aborting >>>>> ERROR: Function failed: do_rootfs >>>>> ERROR: Logfile of failure stored in: >>>>> >>>>> /home/hutch/yocto_1.8_davinci_2/poky/build/tmp/work/am180x_evm-poky-linux-gnueabi/core-image-nodeam/1.0-r0/temp/log.do_rootfs.10336 >>>>> ERROR: Task 7 >>>>> (/home/hutch/yocto_1.8_davinci_2/poky/meta/recipes-core/images/core-image-nodeam.bb, >>>>> do_rootfs) failed with exit code '1' >>>>> NOTE: Tasks Summary: Attempted 2614 tasks of which 9 didn't need to be >>>>> rerun and 1 failed. >>>>> Waiting for 0 running tasks to finish: >>>>> >>>>> Summary: 1 task failed: >>>>> >>>>> /home/hutch/yocto_1.8_davinci_2/poky/meta/recipes-core/images/core-image-nodeam.bb, >>>>> do_rootfs >>>>> Summary: There were 4 WARNING messages shown. >>>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit >>>>> code. >>>> >>>> >>>> More info for those that care ... >>>> >>>> The end of the error log file has: >>>> DEBUG: Executing python function write_image_manifest >>>> DEBUG: Python function write_image_manifest finished >>>> NOTE: Executing: ldconfig >>>> >>>> -r/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/work/am180x_evm-poky-linux-gnueabi/core-image-nodeam/1.0-r0/rootfs-c >>>> new -v >>>> ERROR: No kernel-abiversion file found >>>> >>>> (/home/hutch/yocto_1.8_davinci_2/poky/build/tmp/sysroots/am180x-evm/pkgdata/kernel-depmod/kernel-abiversion), >>>> cannot run depmod, aborting >>>> DEBUG: Python function do_rootfs finished >>>> ERROR: Function failed: do_rootfs >>>> >>>> I have a linux-dummy director in pkgdata but no kernel-depmod directory >>>> exists. >>>> >>> >>> Interesting. Looks like we have some sort of bad dependency. I'm poking >>> around >>> to see if I can reproduce this locally. >> >> >> Brian, >> >> I'm trying to wrap my head around this. Which kernel did you say >> was building in your configuration ? Was it really linux-dummy, or >> is there a bootable kernel in play ? >> >> Looking at the dependencies, I can see how the depmodwrapper requires >> that a kernel be built and the abiversion file created. But in the >> case of linux-dummy, there's no header files to use and generate the >> abiversion, so it won't be available for depmod. >> >> Which takes me back to one of my original questions, why is depmod >> running if the kernel isn't being built as part of this image .. and >> that leads me to think I'm missing some important information. >> >> Bruce > > Hi Bruce, > > Thanks for looking into it. > > I have the meta-ti layer included and in the past, it did build a real > kernel version. I don't know when (because I don't use the kernel > built by the system, I use one from outside bitbake) but this release > (1.8) and last (1.7) has built linux-dummy instead of a real version > and I didn't tell it to. > > Maybe I'm doing something wrong on my end but I built this release the > same way I've built all of them (and I've been doing it from the start > of yocto project). > > The only other layers I use are meta-openembedded and meta-ti. > > Regards, > > Brian
After being off this for a while ... today I did a git pull on all my master based layers, deleted /tmp and rebuilt my am1808 based image with no problems. Never saw a post of a formal resolution to this problem but obviously it was fixed somehow so thanks to whomever that was. Kernel was built as uImage--3.14.43-r0-am180x instead of linux-dummy this time. Regards, Brian -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
