All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@bmw.de>
To: openembedded-core@lists.openembedded.org
Cc: Michael.Ho@bmw.de
Subject: [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
Date: Thu, 29 Nov 2018 14:21:33 +0200	[thread overview]
Message-ID: <1543494097-19534-2-git-send-email-mikko.rapeli@bmw.de> (raw)
In-Reply-To: <1543494097-19534-1-git-send-email-mikko.rapeli@bmw.de>

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

Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
---
 meta/classes/image.bbclass       |  2 +-
 meta/classes/image_types.bbclass | 11 ++++++++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 276d0d3..34a567f 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -127,7 +127,7 @@ def rootfs_variables(d):
                  'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
                  'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
                  'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
-                 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
+                 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS', 'IMAGE_ROOTFS_SIZE_LIMIT']
     variables.extend(rootfs_command_variables(d))
     variables.extend(variable_depends(d))
     return " ".join(variables)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5c40648..0481703 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -125,7 +125,16 @@ IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} ${IMGDEPLOYDIR}/${IMAGE_NAM
 # required when extracting, but it seems prudent to use it in both cases.
 IMAGE_CMD_TAR ?= "tar"
 # ignore return code 1 "file changed as we read it" as other tasks(e.g. do_image_wic) may be hardlinking rootfs
-IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --numeric-owner -cf ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [ $? -eq 1 ]"
+IMAGE_CMD_tar() {
+	set -ex
+	"${IMAGE_CMD_TAR}" --numeric-owner -cf "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar" -C "${IMAGE_ROOTFS}" . || [ $? -eq 1 ]
+	# fail build if IMAGE_ROOTFS_SIZE_LIMIT is exceeded
+	if [ -n "${IMAGE_ROOTFS_SIZE_LIMIT}" ]; then
+		imagesize=$( du -ks "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar" | awk '{ print $1 }' )
+		[ "${imagesize}" -gt "${IMAGE_ROOTFS_SIZE_LIMIT}" ] && \
+		bberror "Image size ${imagesize} of ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar reported by 'du -ks' is larger than limit IMAGE_ROOTFS_SIZE_LIMIT ${IMAGE_ROOTFS_SIZE_LIMIT}"
+	fi
+}
 
 do_image_cpio[cleandirs] += "${WORKDIR}/cpio_append"
 IMAGE_CMD_cpio () {
-- 
1.9.1



  reply	other threads:[~2018-11-29 13:00 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 ` Mikko Rapeli [this message]
2018-11-29 14:04   ` [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type Richard Purdie
2018-11-29 14:17     ` Mikko.Rapeli
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=1543494097-19534-2-git-send-email-mikko.rapeli@bmw.de \
    --to=mikko.rapeli@bmw.de \
    --cc=Michael.Ho@bmw.de \
    --cc=openembedded-core@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.