On a git repo with submodules, such as the intel-iot-refkit, the yocto-autobuilder runs "git submodule update --init --recursive" to fetch the latest version of the submodules. We occasionally see an error in that initial update call about missing objects: From http://git.openembedded.org/bitbake * [new branch] 1.36 -> origin/1.36 ed3aab9..9c0f6e8 master -> origin/master 60d4791..9c0f6e8 master-next -> origin/master-next Submodule path 'bitbake': checked out '9c0f6e81dae0b91b425e6c0cdf64caa5c15d92b5' From https://git.yoctoproject.org/git/meta-intel 0346318..989db4c master -> origin/master Submodule path 'meta-intel': checked out '989db4c0e7db84e52b4e564101a974ef59f1bba6' From http://git.openembedded.org/meta-openembedded d9f7ef4..4496cb4 master -> origin/master + 51fb92e...b597bcc master-next -> origin/master-next (forced update) Submodule path 'meta-openembedded': checked out '4a45235796df0ca1b3bca5407b9615281cf8889d' From https://git.yoctoproject.org/git/meta-security 1014cc6..e180062 master -> origin/master 3352b61..6b7ff79 master-next -> origin/master-next + b9e99f2...54eb59e security-wip -> origin/security-wip (forced update) Submodule path 'meta-security': checked out 'e180062c708483a55390a6adc1efd9e60d2681c5' From https://git.yoctoproject.org/git/meta-yocto 4e0ada1..6909368 master -> origin/master 4e0ada1..6909368 master-next -> origin/master-next b26cac5..b96df6e pyro -> origin/pyro * [new branch] rocko -> origin/rocko Submodule path 'meta-yocto': checked out '6909368e9b193c3fc79257982ec609307a5e1ba4' error: Unable to find 69cbe901a68e627a4c8a351f9fb67af15a07323e under http://git.openembedded.org/openembedded-core Cannot obtain needed blob 69cbe901a68e627a4c8a351f9fb67af15a07323e while processing commit f1dd3d54f1b104e0ab3d3857c4cdc9f6f1ecde9f. error: Fetch failed. Unable to fetch in submodule path 'openembedded-core'
As the intel-iot-refkit repository is only cloned by the nightly-refkit buildset we can likely remove the clone step from the nightly buildset and therefore ensure that a failure to clone intel-iot-refkit only breaks the nightly-refkit buildset, rather than preventing the whole build from running. This doesn't resolve the clone issue but does prevent it from causing the entire nightly to fail.
We haven't seen this issue for some time. Marking as resolved->worksforme