[RFC PATCH] meta/classes: Add strip-image

3 views
Skip to first unread message

Quirin Gylstorff

unread,
Sep 3, 2025, 11:21:04 AM (4 days ago) Sep 3
to isar-...@googlegroups.com
From: Quirin Gylstorff <quirin.g...@siemens.com>

This class provides the optional functionality to strip packages
and files from a image. This allows the user to reduce the image
size.

IMPORTANT: This is an expert feature and can lead to broken images.
Signed-off-by: Quirin Gylstorff <quirin.g...@siemens.com>
---

The default settings will reduce the space around 40MB. It is currently
a RFC to collect information about the usage.

Should we integrate by default or should the user add this on demand?
For a default integration I would drop the deletion:
- /vmlinuz*
- /boot
- /usr/include
- initramfs-tools

meta/classes/strip-image.bbclass | 64 ++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100644 meta/classes/strip-image.bbclass

diff --git a/meta/classes/strip-image.bbclass b/meta/classes/strip-image.bbclass
new file mode 100644
index 00000000..edff3fd4
--- /dev/null
+++ b/meta/classes/strip-image.bbclass
@@ -0,0 +1,64 @@
+# strip image helper
+#
+# This software is a part of ISAR.
+# Copyright (C) Siemens AG, 2025
+#
+# SPDX-License-Identifier: MIT
+# This class provides functions to remove pacakges and files
+# from the image
+
+# Default list of files to be removed:
+# - remove kernel and initrd
+# - remove all documentation
+# - remove all include files
+IMAGE_STRIP_FILES += " \
+ /vmlinuz* \
+ /boot \
+ /usr/share/doc \
+ /usr/share/info \
+ /usr/share/man \
+ /usr/include \
+"
+
+do_strip_files_from_image[vardeps] = "${IMAGE_STRIP_FILES}"
+do_strip_files_from_image[network] = "${TASK_USE_SUDO}"
+do_strip_files_from_image() {
+i if [ -n "${IMAGE_STRIP_FILES}" ]; then
+ cat <<EOF | sudo tee "${IMAGE_ROOTFS}/purge.sh"
+#!/usr/bin/env sh
+set -x
+for elem in ${IMAGE_STRIP_FILES}; do
+ find \$elem ! -type d -exec rm -rf {} \;
+done
+rm -f /purge.sh
+EOF
+ sudo chmod 755 "${IMAGE_ROOTFS}/purge.sh"
+ sudo -E chroot "${IMAGE_ROOTFS}" "/purge.sh"
+ fi
+}
+addtask strip_files_from_image before do_rootfs_finalize after do_generate_initramfs
+IMAGE_STRIP_PACKAGES += " \
+ initramfs-tools \
+ initramfs-tools-core \
+ locales \
+"
+do_strip_packages_from_image[vardeps] = "${IMAGE_STRIP_PACKAGES}"
+do_strip_packages_from_image[network] = "${TASK_USE_SUDO}"
+do_strip_packages_from_image() {
+ bbnote "IMAGE_PACKAGES_REMOVE: ${IMAGE_PACKAGES_REMOVE}"
+ if [ -n "${IMAGE_STRIP_PACKAGES}" ]; then
+ RMPKGS=$(dpkg-query \
+ --admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ \
+ -f '${Package}\n' \
+ -W ${IMAGE_STRIP_PACKAGES} 2>/dev/null || true)
+
+ if [ -n "${RMPKGS}" ]; then
+ bbnote "Removing packages: ${RMPKGS}"
+ sudo -E chroot "${IMAGE_ROOTFS}" \
+ dpkg --purge --force-depends --force-remove-essential ${RMPKGS}
+ else
+ bbnote "Packages have already been purged or could not be found"
+ fi
+ fi
+}
+addtask strip_packages_from_image before do_strip_files_from_image do_rootfs_finalize after do_rootfs_postprocess
--
2.50.1

Jan Kiszka

unread,
Sep 3, 2025, 12:19:54 PM (4 days ago) Sep 3
to Quirin Gylstorff, isar-...@googlegroups.com
On 03.09.25 17:20, 'Quirin Gylstorff' via isar-users wrote:
> From: Quirin Gylstorff <quirin.g...@siemens.com>
>
> This class provides the optional functionality to strip packages
> and files from a image. This allows the user to reduce the image
> size.
>
> IMPORTANT: This is an expert feature and can lead to broken images.
> Signed-off-by: Quirin Gylstorff <quirin.g...@siemens.com>
> ---
>
> The default settings will reduce the space around 40MB. It is currently
> a RFC to collect information about the usage.
>
> Should we integrate by default or should the user add this on demand?
> For a default integration I would drop the deletion:
> - /vmlinuz*
> - /boot
> - /usr/include
> - initramfs-tools
>

The approach isar-exclude-docs takes for docs cannot be used here? And
we want that approach to stay for cleaning docs? Or what is the relation
between the two?

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

Quirin Gylstorff

unread,
Sep 3, 2025, 1:13:37 PM (4 days ago) Sep 3
to Jan Kiszka, isar-...@googlegroups.com
We can use isar-exclude-docs or the use the same implementation. I
didn't use it as it only removes around 3M from /usr/share/docs in my
tests from against an unmodified target.

The second part is that isar-exclude-docs is executed during the pacakge
installation.
Which makes it impossible to remove other files(e.g. /usr/bin/apt-*).


>
> Jan
>
Quirin

Jan Kiszka

unread,
Sep 4, 2025, 4:37:50 AM (3 days ago) Sep 4
to Quirin Gylstorff, isar-...@googlegroups.com
Would be great if we could have only one mechanism in the end that is
powerful enough to express all removal scenarios.

Quirin Gylstorff

unread,
Sep 4, 2025, 5:43:52 AM (3 days ago) Sep 4
to Jan Kiszka, isar-...@googlegroups.com
That would be more possible with the proposed strip-image class as it
works on post rootfs installation. I could extend the class for the
copyrights case of isar-exclude-docs in a v2.

Quirin
>
> Jan
>

Andreas Naumann

unread,
Sep 5, 2025, 3:30:51 AM (2 days ago) Sep 5
to isar-...@googlegroups.com
Hi,

Am 04.09.25 um 11:43 schrieb 'Quirin Gylstorff' via isar-users:
I can image this being a more logical flow than adding packages to
remove things, which feels a bit counter-intuitive to me.

However, I had a quick look and there's already a few removal functions
in the rootfs.class itself. I guess this is where default removals go?

Coming from Embedded, I'm used to rootfs by default having no doc,
man-pages, headers and so on. But maybe Isar has a different policy? Is
it stated somewhere?

regards,
Andreas

>
> Quirin
>>
>> Jan
>>
>
--
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail in...@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

Jan Kiszka

unread,
Sep 5, 2025, 4:43:34 AM (2 days ago) Sep 5
to Andreas Naumann, isar-...@googlegroups.com
Isar is first of all installing real Debian systems, mostly from
original Debian packages. That is primarily happening for embedded
scenarios, but you can also use isar to define desktop images that will
later on be configured and updated by an administrator, the classic way.
So, removing things for embedded, locked-down images should be some
opt-in feature that you can request in your image recipe.
Reply all
Reply to author
Forward
0 new messages