All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

             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.