All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Mikko.Rapeli@bmw.de>
To: <richard.purdie@linuxfoundation.org>
Cc: Michael.Ho@bmw.de, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
Date: Thu, 29 Nov 2018 14:17:10 +0000	[thread overview]
Message-ID: <20181129141709.GB10799@hiutale> (raw)
In-Reply-To: <335a4290d941021b84a2b0447e2017774d0e5259.camel@linuxfoundation.org>

On Thu, Nov 29, 2018 at 02:04:14PM +0000, Richard Purdie wrote:
> On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote:
> > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then
> > build will fail if for tar image type the uncompressed tar ball size
> > exceeds the value, as reported by 'du -ks'.
> > 
> > This check could be extended to other image types as well.
> > 
> > There already exists a check with IMAGE_ROOTFS_SIZE variable
> > but I could not figure out how to actually use it. It does
> > some quite complex overhead calculations which did not seem
> > to work for me on sumo.
> > 
> > When the image size is exceeded, build fails like this:
> > 
> > ERROR: image-1.0-r0 do_image_tar: Image size 170712 of
> > /home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy-
> > image-complete/image.rootfs.tar reported by 'du -ks' is larger than
> > limit IMAGE_ROOTFS_SIZE_LIMIT 170000
> 
> What about IMAGE_ROOTFS_MAXSIZE?
>
> I think IMAGE_ROOTFS_SIZE is about adding extra space to the image, not
> limiting its size...

Yea, forgot to mention that I tried that too but got inconsisten results.
I know it's bad but it was easier for me to add this new test than to figure
out what's wrong with current yocto image size checks. Hence RFC.

-Mikko

> Cheers,
> 
> Richard

  reply	other threads:[~2018-11-29 14:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 12:21 [PATCH 0/5] various fixes Mikko Rapeli
2018-11-29 12:21 ` [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type Mikko Rapeli
2018-11-29 14:04   ` Richard Purdie
2018-11-29 14:17     ` Mikko.Rapeli [this message]
2018-11-29 15:21       ` Christopher Larson
2018-11-29 16:34       ` richard.purdie
2018-11-29 12:21 ` [PATCH 2/5] bitbake: fetch2/svn: Fix SVN repository concurrent update race Mikko Rapeli
2018-11-29 12:21 ` [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs Mikko Rapeli
2019-07-11  2:51   ` Douglas Royds
2019-07-11  4:55     ` Douglas Royds
2018-11-29 12:21 ` [PATCH 4/5] sstate: add support for caching shared workdir tasks Mikko Rapeli
2018-11-29 12:21 ` [PATCH 5/5] insane.bbclass: add package specific skips to sstate hash Mikko Rapeli
2018-11-29 13:33 ` ✗ patchtest: failure for various fixes Patchwork

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=20181129141709.GB10799@hiutale \
    --to=mikko.rapeli@bmw.de \
    --cc=Michael.Ho@bmw.de \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.