From: Henning Schild <henning.schild@siemens.com>
To: "[ext] Jan Kiszka" <jan.kiszka@siemens.com>
Cc: "Maxim Yu. Osipov" <mosipov@ilbers.de>,
hh h <jupiter.hce@gmail.com>,
isar-users <isar-users@googlegroups.com>
Subject: Re: Can isar Debian armhf image size be controlled?
Date: Tue, 5 Mar 2019 11:29:46 +0100 [thread overview]
Message-ID: <20190305112946.39a939af@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <68538b5b-67dc-0836-5f72-3347399522ce@siemens.com>
Am Tue, 5 Mar 2019 07:50:19 +0100
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:
> On 05.03.19 07:32, Maxim Yu. Osipov wrote:
> > Hi,
> >
> > 1) For reference ISAR armhf target - Terasic DE0-Nano-SoC - the
> > current default isar-image-base rootfs gives
> >
> >
> > isar/build/tmp/work/debian-stretch-armhf/isar-image-base/rootfs$
> > sudo du -sh . 163M .
If you have a closer look with i.e "ncdu" you will find that kernel and
modules might require a lot. One way to safe space is using a custom
kernel and not use too many modules, also not use an initrd.
Other consumers are locales/zoneinfo/docs. These things can be cleaned
up i.e. with a postrm script in a transient package. Or a few "rm"s in
a do_rootfs_append or a custom task.
I just manually removed some files and got down to 65MB (kernel and
modules not included).
> > The rootfs is already trimmed from /var/cache/apt entries.
>
> It may be further trimmed (by making it a "non-Debian" image, e.g.
> removing any package management) to something like 120M or maybe even
> 100M. We are planning to provide mechanisms that allow such manual
> tunings during image generation. But then you usually start
> installing your actual application, and its dependencies can blow up
> the image again. We do not know your scenario, so this is hard to
> tell.
Yes you can even remove apt and other "essential" packages, that would
probably be a last resort and give you another 5-7MB.
Note that manual removal of files and removing the package manager
might significantly decrease the value of the rootfs. Depends on
whether you care about updates and how you plan to ship/install them.
> In general, you have to be in a very high volume market so that the
> additional engineering and maintenance costs (when using a
> non-commodity distro) pay off via saved hardware budget.
True! But in this case we are probably talking about an old device that
should receive new firmware.
Henning
> Jan
>
next prev parent reply other threads:[~2019-03-05 10:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-02 22:55 hh h
2019-03-05 6:32 ` Maxim Yu. Osipov
2019-03-05 6:50 ` Jan Kiszka
2019-03-05 10:29 ` Henning Schild [this message]
2019-03-05 11:26 ` JH
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=20190305112946.39a939af@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=jupiter.hce@gmail.com \
--cc=mosipov@ilbers.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox