40 replies to this topic

[XRayhTec]

Probably answer will be very easy, but I cannot find it.

 

After some hours of building I get for do_populate_lic, do_rootfs and a few more a task hash mismatch.

 

Can I disable that check somewhere or does this mean I can start the build proces all over again?

 

Despite these errors it is creating a kernel and a rootfs, but I don' t feel happy about it yet:)

 

Thanks in advance for reply.

 

Regards,

[Erik Slagter]

I had this error as well. Problem is I don't remember how I fixed it  Maybe I remember soon

[XRayhTec]

The Log file indicates:

 

NOTE: task do_rootfs: Started

ERROR: do_rootfs: Taskhash mismatch

NOTE: task do_rootfs: Succeeded

 

NOTE: Tasks Summary: Attempted 7372 tasks of which 7263 didn't need to be rerun and all succeeded.

 

Seems not really an ERROR, but not clear to me by what it is caused.

[Erik Slagter]

Did you google for it?

[XRayhTec]

" The OpenEmbedded build system uses checksums and shared state cache to avoid unnecessarily

rebuilding tasks. Collectively, this scheme is known as "shared state code."

 

It was obvious I changed the code and so the checksum changed, but how often I rebuilded the code, the Taskhash mismatch did not go away and that was a bit strange to me. And the hash was even different with every build.

 

Till I found and changed this in the recipy:

PR = "r${DATETIME}" 

 

Regards,

Edited by XRayhTec, 14 May 2016 - 21:30.

[Erik Slagter]

Hmmm, interesting. I know that with a certain commit in OE this started to happen, so messages on the mailing-list. Maybe it's fixed now.

[Nicker]

In some recipes adding PR[vardepsxeclude]="DATETIME" helps.

[Erik Slagter]

I bumped into the problem once more. And I now remember how I fixed it. I just removed the check in the bitbake code and then all works

[Nicker]

Yes this works for sure ... :-) there is number of another "nice" things that new bitbake versions will complain about... I am trying on my own @ my git (openembedded upgraded to last master commits), and bitbake complains almost about everything :-D I am getting nervous when my server console gets full of this crap, so I use inplace replace by sed in recipes....

[XRayhTec]

Krogoth and bitbake 1.30 working rather good here.

 

Regards,

[athoik]

Hi,

 

 

Anyone knows what bitbake cases the task hash mismach issue?

 

ERROR: openpli-enigma2-image-1.0-r0 do_image_ubi: Taskhash mismatch bdcea613e4cc4cfc66efb44253d8ff5f verses 8140e26349998e105ccf9e9dfd984fc9 for /opt/openpli/openpli5/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb.do_image_ubi
ERROR: Taskhash mismatch bdcea613e4cc4cfc66efb44253d8ff5f verses 8140e26349998e105ccf9e9dfd984fc9 for /opt/openpli/openpli5/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb.do_image_ubi

[WanWizard]

Does this explaination help any? https://patchwork.op...g/patch/120347/

 

A similar one: https://patches.open...g/patch/120303/

[blzr]

I get this taskhash error from time to time too
I build for 3 boxes one by another, and error most often occurs at the last /et9x00/ (funny thing is that image is still built despite this error)
and the next build is ok

maybe adding something like this to openpli-enigma2-image.bb:

IMAGE_CMD_ubi[vardepsexclude] = "DATETIME"

will allow to get rid of this?

[athoik]

I tried the folowing, it didn't work.

 

diff --git a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
index f14d2f0..fc03046 100644
--- a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
+++ b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
@@ -92,3 +92,5 @@ IMAGE_INSTALL += " \
        "

 export IMAGE_BASENAME = "openpli-enigma2"
+KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"

[WanWizard]

I've already been searching through the recipies for {$DATETIME}, but I couldn't find any.

[athoik]

See:

 

$ find meta-openembedded/ openembedded-core/ -type f | xargs fgrep DATETIME
openembedded-core/meta/conf/documentation.conf:DATETIME[doc] = "The date and time the build was started."
openembedded-core/meta/conf/bitbake.conf:DATETIME = "${DATE}${TIME}"
openembedded-core/meta/conf/bitbake.conf:IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
openembedded-core/meta/conf/bitbake.conf:IMAGE_NAME[vardepsexclude] += "DATETIME"
openembedded-core/meta/conf/bitbake.conf:BB_CONSOLELOG ?= "${LOG_DIR}/cooker/${MACHINE}/${DATETIME}.log"
openembedded-core/meta/lib/oeqa/targetcontrol.py:        self.datetime = d.getVar('DATETIME', True)
openembedded-core/meta/lib/oeqa/runtime/_ptest.py:        self.ptest_log = os.path.join(oeRuntimeTest.tc.d.getVar("TEST_LOG_DIR",True), "ptest-%s.log" % oeRuntimeTest.tc.d.getVar('DATETIME', True))
openembedded-core/meta/lib/oeqa/utils/targetbuild.py:        self.datetime = d.getVar('DATETIME', True)
openembedded-core/meta/lib/oe/distro_check.py:    logfile = os.path.join(logpath, "%s.%s%s" % (logfn, d.getVar('DATETIME', True), logsuffix))
openembedded-core/meta/recipes-core/images/build-appliance-image_14.0.0.bb:     zip -r ${DEPLOY_DIR_IMAGE}/Yocto_Build_Appliance-${DATETIME}.zip Yocto_Build_Appliance
openembedded-core/meta/recipes-core/images/build-appliance-image_14.0.0.bb:     ln -sf Yocto_Build_Appliance-${DATETIME}.zip ${DEPLOY_DIR_IMAGE}/Yocto_Build_Appliance.zip
openembedded-core/meta/recipes-core/images/build-appliance-image_14.0.0.bb:create_bundle_files[vardepsexclude] = "DATETIME"
openembedded-core/meta/recipes-core/os-release/os-release.bb:BUILD_ID ?= "${DATETIME}"
openembedded-core/meta/recipes-core/os-release/os-release.bb:BUILD_ID[vardepsexclude] = "DATETIME"
openembedded-core/meta/classes/kernel.bbclass:INITRAMFS_BASE_NAME = "${KERNEL_IMAGETYPE}-initramfs-${PV}-${PR}-${MACHINE}-${DATETIME}"
openembedded-core/meta/classes/kernel.bbclass:INITRAMFS_BASE_NAME[vardepsexclude] = "DATETIME"
openembedded-core/meta/classes/kernel.bbclass:KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
openembedded-core/meta/classes/kernel.bbclass:# Don't include the DATETIME variable in the sstate package signatures
openembedded-core/meta/classes/kernel.bbclass:KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
openembedded-core/meta/classes/kernel.bbclass:MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
openembedded-core/meta/classes/kernel.bbclass:MODULE_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
openembedded-core/meta/classes/kernel.bbclass:# Don't include the DATETIME variable in the sstate package signatures
openembedded-core/meta/classes/kernel-fitimage.bbclass:         its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
openembedded-core/meta/classes/kernel-fitimage.bbclass:         linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
openembedded-core/meta/classes/bugzilla.bbclass:        text     = "The %s step in %s failed at %s for machine %s" % (e.task, data.getVar("PN", True), data.getVar('DATETIME', True), data.getVar( 'MACHINE', True ) )
openembedded-core/meta/classes/toolchain-scripts.bbclass:       echo 'Timestamp: ${DATETIME}' >> $versionfile
openembedded-core/meta/classes/toolchain-scripts.bbclass:toolchain_create_sdk_version[vardepsexclude] = "DATETIME"
openembedded-core/meta/classes/distrodata.bbclass:        datetime = localdata.getVar('DATETIME', True)
openembedded-core/meta/classes/distrodata.bbclass:        datetime = localdata.getVar('DATETIME', True)
openembedded-core/meta/classes/distrodata.bbclass:    datetime = localdata.getVar('DATETIME', True)
openembedded-core/meta/classes/image.bbclass:        # Delete DATETIME so we don't expand any references to it now
openembedded-core/meta/classes/image.bbclass:        localdata.delVar('DATETIME')
openembedded-core/meta/classes/image.bbclass:        d.appendVarFlag('do_image_%s' % t, 'vardepsexclude', 'DATETIME')

[WanWizard]

Yeah, but all relevant entries already have a "vardepsexclude" definition for DATETIME.

[betacentauri]

According to this you should also search for DATE or TIME (I know it's quite old): http://lists.openemb...ber/070146.html

 

And problem can also be in BSP layers from manufacturers and meta-openpli. I also searched but didn't find anything. Is it possible to add more debugs somewhere to find it?

[blzr]

can it because of this, by any chance?
et.inc

IMAGE_CMD_ubi_append = " \
	...
	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
	...
	"

that would somehow explain why I had it only for et9500 build and not for vu nor xsarius,
and also why problem doesn't appear on oe-a (they create it other way...)

[blzr]

ok, after some tests I'm almost sure my suspicions were correct...

for three days I use as follows (copying oe-a approach):
openpli.conf

--- a/meta-openpli/conf/distro/openpli.conf
+++ b/meta-openpli/conf/distro/openpli.conf
@@ -66,6 +66,8 @@ PREFERRED_VERSION_liberation-fonts ?= "1.04"
 
 DISTRO_FEATURES ?= "alsa bluetooth ext2 largefile wifi nfs zeroconf ${DISTRO_FEATURES_LIBC}"
 
+IMAGE_VER_STRING ?= "${DISTRO_NAME}-${DISTRO_VERSION}-${DATE}"
+
 QA_LOGFILE = "${TMPDIR}/qa.log"
 
 OEINCLUDELOGS ?= "yes"

and in et.inc

--- a/conf/machine/include/et.inc
+++ b/conf/machine/include/et.inc
@@ -36,7 +36,7 @@ IMAGE_CMD_ubi_append = " \
        mkdir -p ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}; \
        cp ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/rootfs.bin; \
        gzip -9c ${DEPLOY_DIR_IMAGE}/vmlinux-${MACHINE}.bin > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/kernel.bin; \
-       echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
+       echo ${IMAGE_VER_STRING} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
        echo "rename this file to 'force' to force an update without confirmation" > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/noforce; \
        cd ${DEPLOY_DIR_IMAGE}; \
        zip ${DISTRO_NAME}-${DISTRO_VERSION}-${MACHINE}_usb.zip ${IMAGEDIR}/*; \

and guess what - so far so good - taskhash mismatch error is gone...
we'll see...

however, maybe there's some easier solution that wouldn't require bsp layers adjustments /?/

bart@brtX:~/openpli$ find meta-* -type f | xargs fgrep -w {DATE}
meta-edision/conf/machine/include/rootfs-ubi.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-formuler/conf/machine/include/formuler.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-gi/conf/machine/include/et7000mini.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-hd/conf/machine/include/hd-mipsel.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-hd/conf/machine/include/hd-arm.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-miraclebox/conf/machine/include/miraclebox.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
...
meta-spycat/conf/machine/include/rootfs-ubi.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-xp/conf/machine/include/xp.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-xpeedc/conf/machine/include/xpeedc.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-xtrend/conf/machine/include/et7k.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \
meta-zgemma/conf/machine/include/zgemma.inc:	echo ${DISTRO_NAME}-${DISTRO_VERSION}-${DATE} > ${DEPLOY_DIR_IMAGE}/${IMAGEDIR}/imageversion; \

Edited by blzr, 3 August 2016 - 08:28.