From: Olivier Dugas <dugaso@sonatest.com>
To: <bitbake-devel@lists.openembedded.org>
Subject: Bitbake do_unpack checksum?
Date: Mon, 22 Sep 2014 11:08:06 -0400 [thread overview]
Message-ID: <54203B56.5030607@sonatest.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
Hi all,
[Go to paragraph surrounded by # if in a hurry]
The company I work for is using Yocto (customized version of dylan). We
recently faced a little problem with bitbake and my google-fu seems to
be insufficient to solve it.
I know that when SRC_URI of a recipe is changed, the MD5 and SHA sums
will have to be updated. If not, bitbake will fail with a very verbose
error telling exactly what are the new checksums so I can easily update
them in the recipe.
I also know that a tarball of a recipe might change on a server without
having its version changed. This is a very bad practice but when this
happen we are dealing with it.
No, the problem we're having is not about these well documented cases.
The problem is about rotten bits.
You see, we have a recipe (let's call it foo) that need to be build from
scratch. Bitbake will do_fetch() it, and verify the checksums.
Everything's fine, the tarball is saved in the yocto's downloads folder.
Bitbake then do_unpack() the tarball and starts building in the tmp
directory. Marvellous. The build succeeds and everybody is happy.
Then, say I want to rebuild a yocto image after having modified a recipe
(bar). bar is needed by foo, so foo will have to be rebuilt. No problem
everything is fine. foo is not redownloaded since it's already in
downloads. there's a do_unpack() and so on.
Here's the problem. A week later, I modify bar again, so foo will need
to be rebuilt. A bit on the hard drive flipped so the checksum of foo's
tarball does not match anymore. Apparently and from what I read,
Bitbake's do_unpack does not verify the checksum as it's only validated
during do_fetch. Building and installing foo succeeds though as the
rotten bit only affects runtime. The image is created like no problem
occured and we install the image. Then there's the crash, we search a
lot and finally find the issue. A simple -c cleanall foo and the problem
will disappear.
#
Now, my question : Would it be hard to bitbake's contributors to add a
checksum validation during the do_unpack step? Hard-drive errors like
this can occur, and such above-mentionned pain would be so easily
avoided by a quick checksum...
#
Many thanks.
Lee
P.S.: " If I had more time, I would have written a shorter letter"
[-- Attachment #2: Type: text/html, Size: 3049 bytes --]
next reply other threads:[~2014-09-22 15:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 15:08 Olivier Dugas [this message]
2014-09-22 16:16 ` Bitbake do_unpack checksum? Burton, Ross
2014-09-22 16:18 ` Burton, Ross
2014-09-22 17:04 ` Olivier Dugas
2014-09-22 19:20 ` Burton, Ross
2014-09-22 19:37 ` Olivier Dugas
2014-09-22 22:20 ` Burton, Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54203B56.5030607@sonatest.com \
--to=dugaso@sonatest.com \
--cc=bitbake-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.