Can isar Debian armhf image size be controlled?

Can isar Debian armhf image size be controlled?

[hh h]

[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]

Hi,

I am selecting build system and distro for my small Linux embedded device, 
it has small resources, about 128 MB Flash and 64 MB RAM. The device is a 
typical embedded system, no GUI, no Desktop environment, no multiple user 
interfaces, the C++ applications are simply for data transfer and 
communication using TCP/IP, the applications were previously running well 
on Debian 8 armhf, so isar Debian is my first choice, but the Debian image 
size could be a major problem, it could be too large to blow out the device 
resource constraints, OE or Yocto or OpenWrt image seems much smaller than 
the Debian armhf image. Is it possible to control / reduce Debian armhf 
image size by isar build, to reach the same resource level in OE Yocto or 
OpenWrt?

Also how stable is the isar build for Debian stretch armhf?

Thank you and appreciate it.

Kind regards,

- jh



[-- Attachment #1.2: Type: text/html, Size: 1046 bytes --]

Re: Can isar Debian armhf image size be controlled?

[Maxim Yu. Osipov]

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	.

The rootfs is already trimmed from /var/cache/apt entries.

2) The build for armhf debian stretch is stable (both - native and cross)

Regards,
Maxim.


On 3/2/19 11:55 PM, hh h wrote:
> Hi,
> 
> I am selecting build system and distro for my small Linux embedded 
> device, it has small resources, about 128 MB Flash and 64 MB RAM. The 
> device is a typical embedded system, no GUI, no Desktop environment, no 
> multiple user interfaces, the C++ applications are simply for data 
> transfer and communication using TCP/IP, the applications were 
> previously running well on Debian 8 armhf, so isar Debian is my first 
> choice, but the Debian image size could be a major problem, it could be 
> too large to blow out the device resource constraints, OE or Yocto or 
> OpenWrt image seems much smaller than the Debian armhf image. Is it 
> possible to control / reduce Debian armhf image size by isar build, to 
> reach the same resource level in OE Yocto or OpenWrt?
> 
> Also how stable is the isar build for Debian stretch armhf?
> 
> Thank you and appreciate it.
> 
> Kind regards,
> 
> - jh
> 
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to isar-users+unsubscribe@googlegroups.com 
> <mailto:isar-users+unsubscribe@googlegroups.com>.
> To post to this group, send email to isar-users@googlegroups.com 
> <mailto:isar-users@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/isar-users/884bdd75-b3db-430e-b34f-f84f57e98d48%40googlegroups.com 
> <https://groups.google.com/d/msgid/isar-users/884bdd75-b3db-430e-b34f-f84f57e98d48%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: Can isar Debian armhf image size be controlled?

[Jan Kiszka]

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    .
> 
> 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.

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: Can isar Debian armhf image size be controlled?

[Henning Schild]

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
> 

Re: Can isar Debian armhf image size be controlled?

[JH]

On 3/5/19, Henning Schild <henning.schild@siemens.com> wrote:

> 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).

That is an excellent news, I'll remove /locales /docs and other
desktop resources which are  useless in a specific purpose embedded
system.

> 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.

Yes, I am not going to use desktop style apt update and install from
Debian repository, our firmware and software will be downloaded from a
controlled remote server and installed with dependencies locally.
Obviously, it needs be well tested before starting remote software /
firmware update.

>> 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.

Agreed, thanks Henning and all responses.

- jupiter